RE: Skills
Sun, 19 Jul 92 20:04:37 EDT

Russell Wallace writes:
>I think a simple flat skill system would be best. The main problems people
>seem to have with this are that it makes skills too specialized (e.g.
>if you study BUILD CLIPPER, this should not be useless when you come
>to try to build a schooner), and that it makes ASSASSINATE and TELEPORT
>too easily available.

That pretty much sums it up. But I also think the CURRENT system is
an EXCELLANT (no exaggeration) model for what it is being used for.

>The first can be solved by abolishing unreasonable over-specialization
>in the skill list. Just have a SHIPBUILDING skill. Then maybe assign
>different difficulty levels to building each type of ship, e.g.


>might be at an effective -1 to your skill, whereas

>might be at an effective -3. Ergo, no need for horribly complicated
>dependency graphs, trees etc.

>ASSASSINATE should not be a skill at all, but rather a very high level
>application of the STEALTH skill together with some COMBAT ability
>(in reality, those are the two skills that assassins use, there is no
>special skill for assassination that is separate from other skills).

First, I don't think assassination requires combat. Combat right now
doesn't have a use. If using assissination throws the two parties into
combat, they combat is already factored in. If assassination allows
you to "pick off" another unit -- no save -- then it need not be done
via combat but could be done via poison. As I stated earlier, no
other skills needed if you view the skill this way.

Second, if you get a task called "Assassinate" at a high level of Stealth,
the, essentially it IS a very high level application of Stealth. Those
"secondary skills" represent a specific task you can do with the skill
just like saying "use stealth assassinate [unit]" does. It just gives
the task its own number that you use instead.

Third, giving different skill tasks different difficulty modifers is
probably a useless compexity for a variety of reasons I can go into if
you want. It also may CAUSE problems.

Forth, by giving each task it's own level, you allow for
specialization. Why? If you don't have specialization in individual
task, the game will very quickly have a lot of PCs running around with
a lot of level 10 skills and they will be just like every other PC
with the same level 10 skill. It gives you something to do before or
after you get to level 10 besides adding more levels at the top and it
allows two units who are both high level in a skill to have different
task they excel in and therefore different modes of opperation. One
shipbuilder might know how to build galleys but his "specialty" might
be building clippers.

>TELEPORT is a spell and as such should be capable of being learned only
>after study of the appropriate magic skill. Incidentally, I don't think
>there should be skill levels with magic spells, as I understand there are
>now, just list which spells are known, and if a skill level is required,
>use the general magic skill, or the skill in weather magic, combat magic
>or whatever, if you like. (Similarly if we were doing a system for
>computer programming skill, it would be inappropriate to have separate
>skill levels for different computer programming languages; instead, we would
>just implement a programming skill (or perhaps separate ones for systms
>programming, games programming etc.) and a list of the languages known.)

In a simulation of a skill, there are things that matter and things
that don't. In this game, the things that matter are (A) how good are
you at the skill and (B) what can you do with it at your level. Take
your own computer programming example. It would be pointless in this
game to even WORRY about what "languages" you know. Why? Because
language proficiency isn't the heart of programming. Understanding
instructions, data structures, and techniques is. As you go up in
"Programming", you would learn various techniques. First you learn
"printing", then "decision statement", then "loops", then "arrays",
then "simple data structures", then "pointers", then "advanced data
structures", then "advanced programming concepts". How do I know
this? I have taken over a half dozen programming courses ranging from
High School, through college, to The State of New Jersey and I work at
the Rutgers labs and it ALWAYS goes in pretty much that progression.
Once a person understands an array in BASIC, they can easily learn it
in Pascal or COBOL or Natural 2 or even Lotus. The structure is the
same. Now how does this all realate to Olympia (back to the
subject...). In Olympia, we are concerned with tasks, not concepts.
What you have to ask is what concepts to you nead for what tasks?
Suppose I want a task called "report programming". For that, I need
"printing", "decision statements", and "loops" which makes it a type
of task I can perform at level 3 (assuming 1 task listed above per
level). If I want to do a report program, I would call the task
"report programming". Suppose I want a task called "write sort
program". For that I would need all of the above plus "arrays" and
"simple data structures". It would be a type of task I could perform
at level 5. Suppose I want to do an AI program. I would need up to
"advanced programming concepts", level 8. These DO follow in
progression. Also, there is no way I could do an AI program (a REAL
one) at less than level 8. How does this relate to skill levels for
each sub-task? Now, look not at rating "languages" (which isn't a
good analogy for what is being modeled) but at rating programming
TASKS (which is a good analogy). I work for the State of New Jersey
programming in COBOL on their tax system. I NEVER use anything higher
than "simple data structures". I have taken courses in -- and
understand -- pointers and "advanced data structures" but I NEVER
(*NEVER*) use them at work. There is no need for it. On the other
hand, there might be a person who uses C at work in a research
environment that NEVER writes report programs and HE might not know
much more than "advanced data structures". How are we different? He
might know level 5 in advanced data structures and I might be level 8
in report programs, even though we both "know" the same general stuff,
we practice and use different tasks. I think this sort of divergence
is good. You learn the basics which allow you to perform a task and
then your practice in the task and get better at it. I don't think you
can come up with a better model than the Skill/Task -- both rated --
system Rich has here.

If you want to toss in some complexity, have the base skill level raised
by STUDYing and then have the tasks raised by PRACTICEing or by actually
using the skill. Just an idea...

John Morrow - Varian [856]

Main Index  |  Olympia  |  Arena  |  PBM FAQ  |  Links