Character classes, abilities, skills and other Ygg problems

[Christoffer Lernö]

Ok. I tried to make a new draft of Ygg yesterday and failed miserably as usual.
What I mean by failure is that I found parts of the system which still has problems. I have lots of bits of pieces of system and world sometimes even up to 10 variations of the same (especially with the system part) which I can choose from. I still discover that pieces are missing and without a solid unifying idea to build the system on, any attempts to set down the basics seem to be futile.

The problem is that pieces are interrelated so a change at one place might demand a change somewhere else. That's why the fundamental system idea is so important. Depending on what idea I choose to build on, I will run into different limitations.

What do I mean with idea? Well, basically it's about the character. How is it defined? Through stats? Skills? Abilities? other things?

Combat and actual skill resolution mechanics are all based on this, and try as I might, engineering backwards from a skill resolution and combat system to a character mechanic seem to create a too complicated character creation.

I looked at several alternatives:

* Skills (freely selected) + Stats
* Skills (select from profession) + Stats + Profession (Basically BRP)
* Profession + Stats (this pretty much equivalent to D&D)
* Profession + Stats + Abilities (select from profession)
* Stats

Stats: Mandatory ratings every character possesses

Profession: A regulating template providing selection of abilities or skills

Skills: Skills with or without ratings the character may or may not possess. Skills cover ordinary abilities of people, usually high skill describes extraordinary abilities.

Abilities: Like skills but describes unusual or extraordinary abilities.

The last thing I was working with was Profession + Stats + Abilities.

Basically your profession gave you access to a bunch of abilities from which you initially could choose some. You could develop several professions simultaneously to let you access higher level abilities of those professions. Normal skills would be determined from the stats.

BUT I ran into trouble. First of all is the construction of abilities.

Here's a sample of difficulties to encounter.
1. Abilities may become arbitrary. For example there might be a sharpshooting ability but not a fast-shooting ability. Games using arbitrary abilities usually cover this by making supplements and such. They might even consider this a feature. I feel it's anathema though.

2. Abilities may become thoroughly unbalanced. For example, one ability might give you the ability to sweep and throw your opponent, but how does that measure up to the ability to give extra damage in fighting. They seem to be of different efficiencies and thus makes it tempting to use balancing techniqes, something which still can't stop min-maxing. In the end this leads to a trend towards using some abilities and not others.

3. Attempt at orthogonal abilities is difficult. If you want to construct a system where the abilities don't cover each other, (think Champions and such) you usually have to narrow down the definitions of their uses which in turn tends to leave the abilities with a dead and sterile feeling to them.

4. Even after abilities are defined, there is a lot of other arbitrary decisions to be made, such as effects of increasing levels of mastery. For pure combat abilities, actual advantages might possibly be turned into numerical values, but abilities like extraordinary tracking skill or stealth aren't so easily defined. The problem is magnified when mixing combat abilities with non-combat abilities, as diversifying your character with non-combat abilities necessarily mean that combat skills suffer in the process. I don't want to see this trade-off. Making trade-offs within the group of different combat abilities themselves and the same within the group of non-combat abilities might seem desireable but this runs into trouble as the different professions have different amount of selection in those areas.

These problems led me to consider throwing away this method, as abilities only work if you're willing to throw away flexibility and narrow the abilities down to 10 or 20 in total. Obviously those won't cover all or even most of the possible abilities, so again we're cutting even more player flexibility here.

For a game with a fairly focused premise this might not be a problem, but I feel it definately is.

The thing was that I was going to introduce martial arts and stuff through those abilities. Now with the abilities gone... the same problem happens with the spells where the contradiction between free magic improvisation and the usefulness of pre-written spells creates a problem.

Now, if I would allow myself an arbitrarily complicated system, the problem might not be so acute, but I want it as simple as possible.

Ok, now for an idea I toyed with:

I wanted to have sweeps and throws, maybe flashy kicks and spectacular acrobatics for those who explicitly trained it.

I was going to introduce ED style abilities, like "Acrobatic Attack", "Sweeps & Throws" and similar to cover these things.

But could it be done some other way? Since I already was using "Close Combat" as a kind of stat... why not have a stat or special skill called "Martial Acrobatics"?

Now the cool thing would be that the more you had in this skill, the more you could do without inducing disadvantages.

Maybe usually trying to leap up and kick that guy off the horse would give me a -5 disadvantage. (In some arbitrary system).

But I have Martial Acrobatics 7, so I can subtract 7 from any disadvantage arising from doing complicated martial moves while fighting.

It doesn't give me any advantages to fighting otherwise, just prevents me from getting disadvantages from doing extraordinary things. This prevents the character from having to be unbeatable in order to do cool things. In addition, if an "advantage" mechanism is in place, like Ygg might have, this might regulate how much I can do withing one "advantage move".

There is nothing which prevents one to use the same mechanism with skills. Basically you'd separate skill usage into two categories: One is allowing you to do things better than the average person and the second is allowing you do ignore things which would distract the average person. Usually a skill would be a combination.

For example, let's say the stalking skill. First it gives me a bonus to my stalking roll (which is based on movement) and secondly it lets me ignore x points of disadvantage due to difficult situations like walking on gravel or something.

[Andrew Martin]

...without a solid unifying idea to build the system on, any attempts to set down the basics seem to be futile.

I think you really need to fix this fundamental problem first of all. Otherwise you'll be like the person who builds their house upon the sand -- ending up with a pile of wasted effort.

Designing, constructing and maintaining a RPG is exactly like designing, constructing and maintaing a house, software, bridge, or pair of shoes.

Designing an all purpose RPG is like like designing an all purpose house, software, bridge, or pair of shoes.

How many shoes do you have? Are each pair all purpose? Can you take one pair to a ball, dance all night in them, then go tramping for six weeks in them, then go deep sea diving, and then use them to protect your feet while working on heavy equipment?

Similarly for an all-purpose RPG. Make your RPG to suit your one purpose, use another RPG for your different purposes. Then you will have a:

...solid unifying idea to build the system on,

:)

I hope that helps!

[Christoffer Lernö]

I'm not sure how you mean Andrew. Of course I'm not trying to make a system which satisfies any possible scenario. It's supposed to fit for the world. Given that I have a few criteria I need the game to fulfill. However, they don't seem to be enough to nail down the basic mechanics, and when I choose an arbitrary set of rules which seemingly fulfills the criteria, I end up with a lot of undefined things. It's when I try to define these last parts I end up with contradictory rules.

I'm not quite sure where I'm going wrong, but it might be that I construct a set of rules and then decide that the "flavour" of the rules isn't good enough. There's no definition to that "flavour" thing so I consequently have no clear definition of how to evoke it.

Hmmm.. maybe time to look into that huh?

[Christoffer Lernö]

I started looking into my requirements and when turning over to the character class part I ran into these things:

"Character archetypes should include"

Wise Male Troll Mystic who can perform strange magic and fight with a staff when needed to. Does not use armour.

Big Basher Troll Fighter. Fights with simple weapons as clubs and only wears really light armour.

Dangerous Female Troll Mystic. Compared to the male troll her skills are much more seducing and dangerous. Usually able to use smaller weapons and might wear light armour.

Martial Artist who fight just as well without weapons and armour as fighters with swords and armour. Might use specialized weapons like iron claws (only on one hand)

Swordmasters and others. These wear varying types of armour, cool swords and weapons. All are skilled at armed martial arts.

The Sorceress/Sorcerer who REALLY literaly glows magic and is no stranger to weapons and fighting. Might have a demon servant or at least a familiar. Summons demons to do tasks.

The Archer who can hit anything at a distance. Usually with light armour and amazing stealth skills. May or may not be decent at swordfighting as well. The archer tends to be a great hunter and tracker as well.

A Shapeshifter of the Witchpeople who wears little armour and light weapons but outclass ever the Archer in stealth. Usually fights hand-to-hand in shapeshifted form.

A Warrior of the Witchpeople who enters battle covered with magical warpainting and little armour but usually not barehanded.

A Dwarf of the Slayer sect with mystical runes on his body to gain magical strength in battle. Slayers are a dwarves who voluntarily have tattoed dwarven mystical runes to gain greater strength. They are shunned by the rest of the dwarven society.

A Goblin Fortuneseeker with his knowledge of languages and screwd abilities of negotiation and thievery. These are Goblins who has gone into the world of men trying to make a fortune for themselves.

"Each character type should be able to act out their uniqueness"

Troll mystic will be able to make use of his innate abilites, usually of clairvoyance, true seeing, creating glamour and divinations.
The troll mystic is very learned in the subject of myths, legends and history.

The Big Basher Troll is a brutish fighter with little elegance. However due to his great strength he's a force to be reconed with. He'll be able to throw great rocks and other feats of strength as well as being hard to harm in combat and when he hits it really really hurts. Noone can take as much damage as a Big Basher Troll.

Dangerous Female Troll Mystic has great allure and powers of seduction. They know great powers of glamour and clouding the minds of people. They are knowledgable in healing and divination as well. Some are even accomplished shape shifters.

The Martial Artist is usually human. The Martial Artist is trained in martial acrobatics and the use of inner power. Through this he/she can withstand more damage and is very hard to hit. When hitting he/she can do great damage despite only using kicks, punches and throws. The MA's hits can do internal damage which is hard to see. Because of his/her great skill, he/she might even have learned to deflect arrows and stuff (certain swordmasters may also learn this)

The Swordsmaster has learned his weapon to perfection. He can use it at great abilitiy and might even have learned some martial acrobatics although the later is virtually useless in heavy armour. Some swordsmen however, don't use armour and might so be very like the martial artist except for the weapon used.

The Sorcerer/Sorceress uses spells and gets increasingly more warped by the demonic magic used.

The Archer is the crackshot. Anyone can use a bow, but archer excells at it. There are both human and witchpeople in this group. The Archer is usually a good sniper and as such has learned stealth. Tracking and hunting are also abilities associated with the Archer. The Archer will be able to hit things more accurately and at further distance than other people. In addition he/she might be able to run and fire and do other similar stunts. Riding and shooting? No problem. The Archer knows it. Or making fire arrows or whistler arrows or whatever.

... and so on...

Now this seems to imply that I should try to avoid making generic character classes independent of race.

Basically my old scheme was class + race = archetype. If I go with character classes, they should be linked with the race to get advantages from this method.

Of course the drawback again is to create the abilities of the character classes. Oh hoo hum. This is almost tempting to become D&D (not AD&D) isn't it?

[Valamir]

The reason you're still having this kind of difficulty is because you still haven't decided what your game is to be ABOUT.  You have a zillion different cool ideas from a zillion different sources and the only unifying factor is you thinking "wouldn't it be neat if I had ALL of those things in MY game".

The answer is, no it wouldn't.

The kitchen sink approach doesn't work.  I don't think its ever really worked.  I think many of us worked with it because we thought somehow that that was what games are supposed to be...but it never really did work.

What is your game ABOUT.

If I was playing Trollbabe and told Ron I wanted to play an Ork he'd say "go play Orkworld then".  If I was playing Dust Devils and told Matt I wanted to play Zorro he'd tell me to go play Zorro.  If I was playing Sorcerer and wanted to play a secret agent sniper assassin with no magic abilities whatsoever I'd be better off playing Millenium's End.

Point being, you're trying to make a game where you can be and do anything.  Your only criteria is some vague sense of "if its in fantasy, it must be in my game"  But not only is that not helpful, its not even very accurate.  There are no Dwarves in Elric.  Conan never once encounters a halfling.  You don't need to put every cool thing you've ever thought of in one game.  I've said before you don't need to even create an entire world all at once.

Figure out what players are supposed to do.  Is it about duelling combat between master fighters.  Is it about hunting down evil monsters.  Is it about maneuvering for position in the kings court, etc.  

If your answer is "yeah it could be any of those" then frankly my response at this point has got to be..."big deal, there are two dozen games I know of already that do that...I'm not interested in another one".

Pick one...ONE....ONE ONE ONE thing that your game is about.  Fashion a character creation system that can ONLY create that type of character.  Put in big letters in the character creation chapter  "if you want X go play something else".  Make your game about that one thing.   Do that one thing better than any other game has ever done it.  Do it better than any game that trys to do everything could ever do it.  THEN you'll have a game I'd be interested in playing and owning.  Make another D&D variant and quite honestly...been there...seen that.

[Christoffer Lernö]

Of course I know I can't get it all. So yes, I'm focusing on the monster hunting/treasure finding angle, being heroes because they are the only ones who can do the job. Because they are above average and because they are the stuff that heroes are made of. It's not about dueling, it's not about delicate court intrigue. The characters are supposed to run around in the wilderness and have a reason for it.

I hope the example archetypes reflect that decision. Let me know if they don't.

[Andrew Martin]

...I'm focusing on the monster hunting/treasure finding angle, being heroes because they are the only ones who can do the job. Because they are above average and because they are the stuff that heroes are made of. It's not about dueling, it's not about delicate court intrigue. The characters are supposed to run around in the wilderness and have a reason for it.

You seem to be describing D&D3E. :) What exactly about D&D3E would make it unsuitable for what you describe above?

[Bankuei]

The reason you're still having this kind of difficulty is because you still haven't decided what your game is to be ABOUT. You have a zillion different cool ideas from a zillion different sources and the only unifying factor is you thinking "wouldn't it be neat if I had ALL of those things in MY game".

PF, I think this is really the truth of the matter.  When you first posted, the question that was applied(that everybody gets) is "What is your game about?"   To reiterate some very clear examples of games with strong premise:

Inspectres-You ghostbust
Draconic- Kill dragons
Questing Beast- Arthurian Fantasy

Even D&D boils down to- Fight Monsters.

You've been quite prolific in terms of working on it, posting and gathering ideas, but... No one else can tell you what you want.  Until you have that clear, there's not much help we can give you.  Remember, you can always make more games.  No game is the be-all end-all, and there is no "perfect system".

Here's what I suggest, walk away from Ygg for about a month or two, just play games.  Figure out what you want, what you like and dislike, and get a very clear idea of what you're looking for.  Then come up with some rules.  Play them a lot.  Fix them.  Then play them some more.  Then come back and talk to us.  Taste your recipe before sharing.

This will save you a lot of time, and also garner you quite a bit more help.

Chris

[Christoffer Lernö]

Maybe I should have made things clearer to begin with, I'm not sure if you're actually offering advice on how to solve my problem or if you're giving me advice on what you THINK my problem is.

To state it more clearly then: my problem is that the rules keep mutating as I'm writing them.

I start out with a basic rule mechanics idea, but then I write myself into a corner somehow and I feel there is no way to escape an immense amount of patches on the rules.

It's easy enough to write a basic layout of the mechanic, it's when I go into details I notice that the details sometimes want to contradict each other. Or in other words, facilitating one thing makes something else harder to implement in the rules.

As for what Ygg is about, isn't that already sufficiently dealt with in other threads? I can cut and paste from them if you want?

And no Andrew, you can't bait me with the "why not AD&D" posting. I'm getting used to it by now (and it's boring to answer it again since I already answered it a few times already).

[Le Joueur]

My problem is that the rules keep mutating as I'm writing them.

I start out with a basic rule mechanics idea, but then I write myself into a corner somehow and I feel there is no way to escape an immense amount of patches on the rules.

It's easy enough to write a basic layout of the mechanic, it's when I go into details I notice that the details sometimes want to contradict each other. Or in other words, facilitating one thing makes something else harder to implement in the rules.

Try looking at it this way.  If you get a good basic mechanic that you really like but then write yourself into a corner sorting out the details, then your problem is not one of focus.  It is a problem of resolution.

Let me back up a bit here.  Do you understand the difference between a design and a design specification?  Let's compare fighter aircraft; say a B-52 and an F-16.  Both are warplanes, they cover a wide variety of missions.  The each have two wings, two elevators, a rudder, cockpit, and landing gear.  Both are powered by jet engines.  Are they the same?  Hardly.

What you seem to be doing is sitting down to build a warplane without making any design specifications.  People keep asking you, "What's it for?" but I don't think they're asking the right question.  Back to the planes; when they sat down to design the B-52, they wanted to build a bomber.  It was meant to fly very high, carry a whole lot, and drop it.  Ordinance on target is the basic premise, all the design specifications serve that.  Before picking engines, engine configurations, crew size/placement, they decided how far and high it had to fly, how much it could carry, all the different types of things it could carry and drop; all those 'bombery things.'  The blueprints sprang from meeting those needs.  The design specifications came first.

Now let's look at the F-16; it's a light, agile air-to-air attack craft.  It can't take much punishment, but it can sure put a hole through someone's air defense in a big hurry.  The design is based on speed, manueverability, pilot's visability, and handling.  A B-52 has no handling, but boy does it have range.  An F-16 may not have range, but I believe it can land on an aircraft carrier (something out of the question for a B-52).  They're two completely different aircraft for completely different types of aerial warfare.  Can you see how the design specifications come before the design?

You can't build a warplane that does everything.  It's just not possible, even the F-15 Eagle (I believe it's called an 'air superiority fighter') doesn't do it, even though its design specifications are based on versatility.  (It can drop bombs, but not as much as a bomber; it fan dogfight, but not as well as the more agile planes; it has twin, powerful engines and can maintain a velocity straight up, but it doesn't beat spy planes for altitude.)  The point is they pick 'what it was for' before they started; and they knew how the mix of purposes inhibited how well it could perform each.

How does that apply to game design?  I'm glad you ask.  Let's talk Scattershot for a minute (it's the only game system that I know how it was designed).  It had some very clear design specifications from the very, very beginning.  First off, it was going to be a 'generalist system,' that's a game whose rules support more than one application of genre, especially a wide variety (think GURPS).  Second it had to be 'simple;' not undetailed or rudimentary, but that a few robust mechanix would be written to apply in several seemingly different situation.  Third it had to be fairly customizable; spells, powers, magics, psionics, supernatural stuffs had to be easily grasped, obvious to modify, and common to customize.  Fourth, it had to be 'easy to pick up' for 'old school' gamers.  And yet, fifth, break some new ground and be distinctive enough to have its own identity 'in the market.'  Lastly, it had to be 'transparent enough' that 'your mom' could be taught how to play in less than an hour.

Later design specifications led to delineating 'how many' different games it would be that, in turn, affected the ways that the mechanix would be 'robust.'  It had to have a practice of providing concrete and usable examples (for 'old schoolers'), yet these must also be customizable.  And most important, how all this meant that is supported 'genre fusion.'

These were all decided upon outside of the actual game design cycle.  They pushed us to ask some really intriguing questions along the way.  You're pretty familiar with one of the earliest one prompted by 'simplicity;' "can we get by without a 'mechanical initiative system?'"  Another was "why are superpowers different from magic on the 'what is energy' level?" prompted by the 'generalist' goal.  You can see the 'simplicity' at work when you notice that a skill is the same as a power is the same as a spell and all resolution uses the 'hidden' contested roll scheme.

As the need for 'generalism' grew and grew, I was forced to invent Transtional gaming (intentional drift that is facilitated by the game).  The reward mechanic had to be pushed farther and farther into the forefront to 'power' the various uses across the whole Transitional panarama.  And so on.  Meeting the needs of the design specifications is what forced innovation, much like in the aircraft industry; and that delivered on the 'distinctive' design specification in spades.

What does this have to do with Yggdrasil?  Well, it sounds like you have a clear idea that you want to have a 'simple' mechanic, yet when you get into the drafting, you find yourself motivated to pursue smaller and smaller minutia (the need for 'patches').  Let me make something clear; you cannot write a 'simple' system that 'hard codes' detail.  It's a contradiction in terms; a detialed, simple system.  At a 'design specifications level,' you have to make a choice; are you going to address those specific situations or are you going to have a 'simple' way to explore them.

Take for example the whole 'hit location problem.'  As much as I wished I could've, I couldn't put them into Scattershot.  As much as I wanted, I could not put in extensive mechanics for aiming, opportunity fire, and the like.  What could I do?  I created the Challenge system.  You want to 'go for the throat?'  Take that as a Challenge.  You want to wait your shot until they peek through the window?  Hold your shot and 'take the Challenge.'  You want to aim?  Take longer and 'take the Challenge.'  I don't have to make up rules for all those different situations, I just need to describe how to recognize them and conclude their bonus or penalty.

So, does that help understanding what kinds of things people are asking for when they say, "What is your game about?"  Come up with some design specifications; guidelines if you will, in general, to look back upon when the temptation to create 'a patch' for your system.  There are many types of games, some are 'simple,' others don't appear to have 'special case rules' because they aren't anything but.  Decide where you game falls in that kind of spectrum, pick your own 'design specifications' and when you're tempted to 'go beyond' them, stick to them (or, as we've done, take out those rules that 'violate' your design specifications).

Hope the advice helps.

Fang Langford


p. s. One of the hardest things we've had to do is pull the design specification in for redesign.

[Mike Holmes]

Christof,

What Fang is saying is that it's not a lack of focus that plagues you, per se. You know that it's about Killing monsters, etc. You have the general idea of the ABOUT that Ralph refers to. What you don't have is a vision of that focus. So, to add to Fang's analysis, here's the process that one needs to do.

1. Decide on a focus or what the game is about. For a plane, that means what it does generally: bomber, or fighter, etc.
2. Get a vision. This is the design specification part that Fang Mentions. What does it mean to be a fighter or a bomber in this particular case?
3. Design the game. For a plane, this is where you take the spec and actually start putting the game together.

You are tying to go from #1 straight to #3. Every time a question comes up, in #3, you have no answer because you have not done #2. If you had a vision of what the game is supposed to do (other than "work well") then you'd always have your answers when you had problems in #3.

Until you back up and finish #2, get a vision of what the game is supposed to be about, nobody, not yourself or anyone else, can help you finish the game. All we can do is to say, "Well, if x is what you want do y will work. If a is what you want do, then b will work." Since you don't know what x and a are, this advice is useless. x and a are exactly that design spec that Fang speaks of, what I call vision.

Now, I'm sure that, once again, you'll claim that we're not listening to you. That you have set down your problem here, and we are ignoring it. What we have here is a failure to agree on where the problem arises. It's hard to provide continuing support (I gave up a long time ago) to someone who doesn't know what to do with the advice given. So we hedge, and ask if you've really gotten that vision instead of just ambling along in the dark. It comes to a head in this thread once more because you have come very close to identifying the particular problem yourself.

I tried to make a new draft of Ygg yesterday and failed miserably as usual.
What I mean by failure is that I found parts of the system which still has problems. I have lots of bits of pieces of system and world sometimes even up to 10 variations of the same (especially with the system part) which I can choose from.

And you say this sort of stuff again and again. Like we can provide you with some sort of formula for knowing what is right and what is wrong. Don't you think that if such a formula existed that we would have used it long ago to create the game you're trying to design? There is no such single formula, there are only separate visions. Hence you get Clinton with Dunjon, Lance with MageBlade, and the jillion other systems that do get made. They are all about the killin monsters idea; the difference is that all these authors had a vision of what they wanted.

Anyone without a vision has exactly the same problems as you describe in the quote above. Them and perfectionists. If you have a vision, suddenly one of these "parts" will jump out at you and say, pick me! Until you have that vision, that will not happen, and you will never, never, never, finish the design.

An urge to design a game is not the same as a vision.

Mike

[Andrew Martin]

If you have a vision, suddenly one of these "parts" will jump out at you and say, pick me! Until you have that vision, that will not happen, and you will never, never, never, finish the design.

I agree. Once you have that vision, it will become so powerful that the pieces and components of the game will almost fly towards you and force themselves into the system. You'll be almost helpless as the design manifests itself in your head, and demands writing down and being played/used. That's what a vision is like.

I hope that helps!

[Christoffer Lernö]

You might very well be right. I don't know. Can't it simply be that I have a vision, but not a clear vision of it?

Like you correctly point out, I have a lot of ideas and it looks like I'm trying the kitchen sink idea of putting everything in there and stir the pot.

Still, aren't there plenty of (bad) examples of that approach that actually get completed too? I'm wondering if I'm too much of a critic of my own works to let substandard stuff persist too long, or why is it that I can't get it done where others can despite no firm vision? :)

What I'm trying to do now is to actually write a specification on the important parts. The archetypes to be "supported" by the game is one part of it. I'm also writing down how I want the stats to work and what they should describe, why I have stats. What skills are and what they should describe, how conflicts should be resolved, when dice should be rolled and what they should resolve, how complicated modifications and similar should be and so on.

This seem to be in line with Fang's design specs. However, what about the "vision" which Mike and 'drew is arguing about.

Andrew almost seem to say that with a vision you don't need written specs.

So I'm wondering about the vision thing. I have a very clear SENSE of what is ok and what isn't ok. However, while some areas are very clear-cut, others are rather unspecified. For example, while it is clear to me that I want stats, I'm not sure about the skills, they could be in there, I could throw them out, it's all about whether they help achieving other goals or not. It's like that with a lot of things. I'm not sure if I want the rule or mechanic because it has to do with whether it facilitates other things. It's this interdependence which prevents me from completing and freezing parts of the system.

But back to the vision. While I have a clear vision about some things, other parts are rather hazy. So I wonder if this is due to me not having a clue at all or simply because my vision is only partly complete. If it's the former or the latter I should do very different things with Ygg. I hope it's the latter and that writing things down will sort out the hazy areas and give me a complete overview. But that's only what I hope.

[Andrew Martin]

Andrew almost seem to say that with a vision you don't need written specs.

On reflection, I've found that when I'm uncertain of my direction or vision, I write down the desired end result, like drawing a picture of a software layout, or the layout of components. This helps to clear the vision of what I want. Then it becomes straightforward again, and things start happening again.

So give that a try, don't concentrate on local, small scale matters, just concentrate or visualise or draw or write the desired end result, then keep refining that vision; only include those simple bits (YAGNI) that move you directly from here and now to your future goal.

YAGNI: You ain't gonna need it.

I hope that helps!

[Le Joueur]

Like you correctly point out, I have a lot of ideas and it looks like I'm trying the kitchen sink idea of putting everything in there and stir the pot.

That is a workable design approach, provided you have the time to let the stew simmer before you serve it.  Time seems to be your enemy; skip this approach.

Still, aren't there plenty of (bad) examples of that approach that actually get completed too? I'm wondering if I'm too much of a critic of my own works to let substandard stuff persist too long, or why is it that I can't get it done where others can despite no firm vision? :)

No actually this scores quite clearly on your problem.  Being this kind of critic is great, provided you have 'standards.'  These are what I was talking about, when I mention design specifications.  You don't have a clear standard of what to leave in and what to take out; these are the design specs.  For example, one day you're over-critical and take something that would stay in on a good day; I suspect that you don't have the consistency that I'm suggesting specs provide.  (Personally, I think 'vision' is really great, but I've been burned by that before; it assumes talent.)

What I'm trying to do now is to actually write a specification on the important parts. The archetypes to be "supported" by the game is one part of it. I'm also writing down how I want the stats to work and what they should describe, why I have stats. What skills are and what they should describe, how conflicts should be resolved, when dice should be rolled and what they should resolve, how complicated modifications and similar should be and so on.

This seem to be in line with Fang's design specs.

These aren't design specifications, they're the actual design.  A good place to start a design specification is 'how much detail' you want.  It's not whether there are or are no stats, it's how many numbers you want to see on the page.  It's not when dice are rolled, but whether there are dice or not (and how much emphasis 'dicing' should have).

If you are thinking about what stats are to do what, then you're designing the game not the specs.  If you're listing archetypes, then you haven't even addressed if that's appropriate in your specs.

However, what about the "vision" which Mike and 'Drew is arguing about.

Andrew almost seems to say that with a vision you don't need written specs.

That's exactly what they're saying.  I've long felt that 'vision' is a less deliberate form of specs.  I'm deliberate; visions come, visions go, I like to work from explicit design specifications.  A game designed by a designer with a strong, 'clear' vision is designed the same as I would with a set of specs.

So I'm wondering about the vision thing. I have a very clear SENSE of what is ok and what isn't ok. However, while some areas are very clear-cut, others are rather unspecified. For example, while it is clear to me that I want stats, I'm not sure about the skills, they could be in there, I could throw them out, it's all about whether they help achieving other goals or not. It's like that with a lot of things. I'm not sure if I want the rule or mechanic because it has to do with whether it facilitates other things. It's this interdependence which prevents me from completing and freezing parts of the system.

At the speed you're stressing 'getting your game done,' you're going to need something a little more clear than a "sense" of what you want.

Tell me; is it something like this: you get 'the urge,' you feel your "clear sense," so you sit down and start typing.  The introduction rocks; you get into stats and then skills.  You start seeing options you might take, detail you might want to include.  Hours have passed.  You start to lose sight of your "clear sense."  The things you write in the middle of the skills don't seem to fit what you put for the stats.  Eventually, you stop realizing you're second guessing parts you haven't even got a clear insight about how to address chapters away.

Is that how it is?  I know the first few abominable drafts of Fish or Sofa were just like that.  By the fourth or fifth 'fresh' draft, I had gotten into the habit of 'saving the best bits' from previous attempts.  Slowly I learned to block out what I was going to write before I started.  I learned the value of a good outline.  Then I ran smack into the 'what order do you put the guts of a game' problem.  (Character first or world?  Mechanics first or flavor text?  All very complicated.)  Finally I learned that the introduction is the last thing you write; if you can't get pumped about how cool the game is by that point, it probably isn't worth printing.

What I finally decided was that I design best incrementally.  First I decide how I want to approach the genre, where the focus lies and what 'kind' of game best suits it.  (For example, if I were going to do a game for dungeon crawling, it certainly wouldn't go into all the detail of Advance Dungeons & Dragons.  I'd keep it tight and focus on the 'us versus them' aspect of 'going there and coming back alive.'  But that would be Clinton's Donjon wouldn't it?)  How much 'yarn-spinning' should there be?  Will the dice compete for that time?  How many numbers will the game have to have?  How much detail will there be?

Only when I have that locked down do I start designing.  First a 'core resolution mechanic;' maybe one that suits the color of the game (cards and poker chips for a 'western,' tarot cards for mystical, and so on).  I begin working out the details of how the mechanics function when they're appropriate.  Without my design specs in my back pocket, I can't tell how much 'mechanics play' is appropriate and how often the dice (or tables or whatever) should come out, how can I even begin to delve into the detail to support.

Then I work backward.  If stats are warranted, how many and what suits the genre?  If skills are the way to go, how many should I write and how many do I leave to the players?  Will the game be about battle?  Should I skip a combat system altogether?  So on and so on, until I have a bunch of stuff.  Then I go back with the pruning shears.  If I did it write there's 'enough bush' that I can get a decent topiary out of.  One thing I like to do is 'compound' the mechanics.  If I have skills work this way here, maybe I can have stats work the same way over there; fewer rules to remember, but that's just me.

After all that, only then do I consider how to present it.  How much do I need to explain (the amount of raw text is something else I put into my specs)?  How much work will I ask the consumer to do?  Do I spell everything out or leave it all in their hands?  (This can be very important in the specs; a game where the players must furnish lavish descriptions for their spells must not list out all spell details, for example.  That comes up even before you get to writing the spell rules because it should be a common theme throughout the rules.)  Even the gross approach to the expression of the game should be in the design specifications.  (Thus if your writing for a 30 page booklet, you'll stop yourself from writing up those 100 spells and save them for another game.)

That brings up an important point.  No idea is so good that you can't put it aside for a different game.  This might also be your problem.  "Oh this is so cool.  Oh that is so cool.  Hey this here is cool too!"  Yet the three things don't belong in a game together.  If nothing else, remember this.  You're gonna do it again.  That's right, this will not be the only game you write.  You don't have to put everything you write into it or lose it forever.  Save some stuff back, you never know when you'll be struck with another game idea and the 'saved up' stuff will be perfect for it.

But back to the vision. While I have a clear vision about some things, other parts are rather hazy. So I wonder if this is due to me not having a clue at all or simply because my vision is only partly complete. If it's the former or the latter I should do very different things with Ygg. I hope it's the latter and that writing things down will sort out the hazy areas and give me a complete overview. But that's only what I hope.

My main piece of advice, take it easy.  You're making this seem like a life-or-death; do it once or it'll never happen kinda thing.  I've been working on the same game for over ten years now (and I've written a lot of other tidbits in between).  Convince yourself that you can write more than one game and that there isn't so much need to finish so quickly.  It'll come, ya just gotta give it a chance.

And most importantly; play it.

Even if it isn't done or something needs to be completely changed, just play it.  There's nothing more instructive than flight-testing a new aircraft, putting it through its paces.  When NASA started messing around with canards (a wing configuration that the Wright bros. used, but few have since), they started by sticking them onto basically an off-the-shelf F-5 (or was it the F-16, I forget).  They got great data out of the flight tests and it wasn't even a new aircraft.

Good luck and have fun.

Fang Langford