May 1998
- OT: CGDC Adam Wiggins
- OT: CGDC Mike Sellers
- There can be.. only ONE! (fwd) Ling
- There can be.. only ONE! (fwd) Matt Chatterley
- Some thoughts on languages and users - was: Ma Jon A. Lambert
- Some thoughts on languages and users - was: Ma Chris Gray
- Some thoughts on languages and users - was: Ma Adam Wiggins
- Some thoughts on languages and users - was: Ma J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfi Jon A. Lambert
- LIST: The "MUD-DEV" MUD Development mailing list J C Lawrence
- Wired, UO, Mike Sellers
- Wired, UO, John Bertoglio
- Wired, UO, and Internet Gaming (was OT: Dr. Cat
- Wired, UO, and Internet Gaming (was OT: Koster, Raph
- Wired, UO, and Internet Gaming (was OT: J C Lawrence
- Wired, UO, and Internet Gaming (was OT: John Bertoglio
- OT: Supporting articles found for UOL play style Jon A. Lambert
- PK's: A solution? J C Lawrence
- Preview of Asheron's Call J C Lawrence
- Asheron's Call Interview with Toby Ragaini, Lead Designer, and Jon Grande, Product Planner. J C Lawrence
- Character maintinence - expenditure of resources Adam Wiggins
- Character maintinence - expenditure of resources Dan Shiovitz
- Character maintinence - expenditure of resources Adam Wiggins
- Character maintinence - expenditure of resources J C Lawrence
- Character maintinence - expenditure of resources Koster, Raph
- Character maintinence - expenditure of resources J C Lawrence
- Character maintinence - expenditure of resources John Bertoglio
- Character maintinence - expenditure of resources J C Lawrence
- Motivations for Creating Mud-Like Worllds and Servers | John Bertoglio
- FW: (Fwd) Bouncing mail J C Lawrence
- FW: (Fwd) Bouncing mail John Bertoglio
- FW: (Fwd) Bouncing mail Matt Chatterley
- FW: (Fwd) Bouncing mail s001gmu@nova.wright.edu
- FW: (Fwd) Bouncing mail J C Lawrence
- FW: (Fwd) Bouncing mail s001gmu@nova.wright.edu
- FW: (Fwd) Bouncing mail J C Lawrence
- Character development [was ] Koster, Raph
- Motivations for Creating Mud-Like Worlds and Servers Holly Sommer
- META -- membership Jay Sax
- META -- membership Koster, Raph
- META -- membership J C Lawrence
- Motivations (was something else...) s001gmu@nova.wright.edu
- Motivations (was something else...) Richard Woolcock
- client UI written in server's language (was Some thoughts...) Erik Ostrom
- Some thoughts on languages and users - was: Ma J C Lawrence
- Some thoughts on languages and users - was: Ma Travis S. Casey
- Some thoughts on languages and users - was: Ma J C Lawrence
- META: Character of the list's membership J C Lawrence
- quickie CGDC report Mike Sellers
- quickie CGDC report Adam Wiggins
- Some essays I've written lately Koster, Raph
- Some essays I've written lately Koster, Raph
- Some essays I've written lately Koster, Raph
- Some essays I've written lately Koster, Raph
- Some essays I've written lately Koster, Raph
- Some essays I've written lately J C Lawrence
- Some essays I've written lately Koster, Raph
- Some essays I've written lately J C Lawrence
- Some essays I've written lately J C Lawrence
- Frandel 3D (fwd) Holly Sommer
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Raph Koster
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Koster, Raph
- MURKLE: Wot it is Dr. Cat
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Shawn Halpenny
- MURKLE: Wot it is Mike Sellers
- MURKLE: Wot it is Nathan F Yospe
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Chris Gray
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Chris Gray
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Ling
- MURKLE: Wot it is Oliver Jowett
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Ling
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is Ling
- MURKLE: Wot it is J C Lawrence
- MURKLE: Wot it is jacob langthorn
- MURKLE: Wot it is Jon A. Lambert
- MURKLE: Wot it is J C Lawrence
- We're Tiny, we're Toonie, we're all a little Loonie! Ling
- META: Search features of the MUD-Dev archive J C Lawrence
- CGDC, a summary Adam Wiggins
- CGDC, a summary Koster, Raph
- CGDC, a summary Holly Sommer
- CGDC, a summary Caliban Tiresias Darklock
- CGDC, a summary J C Lawrence
- CGDC, a summary Chris Gray
- CGDC, a summary J C Lawrence
- CGDC, a summary Marian Griffith
- CGDC, a summary J C Lawrence
- CGDC, a summary Koster, Raph
- CGDC, a summary J C Lawrence
- CGDC, a summary J C Lawrence
- CGDC, a summary Mike Sellers
- CGDC, a summary J C Lawrence
- CGDC, a summary Chris Gray
- CGDC, a summary Travis S. Casey
- CGDC, a summary Koster, Raph
- CGDC, a summary Adam Wiggins
- CGDC, a summary Koster, Raph
- CGDC, a summary Chris Gray
- CGDC, a summary Koster, Raph
- CGDC, a summary John Bertoglio
- CGDC, a summary s001gmu@nova.wright.edu
- CGDC, a summary John Bertoglio
- CGDC, a summary Koster, Raph
- CGDC, a summary s001gmu@nova.wright.edu
- CGDC, a summary J C Lawrence
- CGDC, a summary John Bertoglio
- CGDC, a summary Koster, Raph
- CGDC, a summary Joel Kelso
- CGDC, a summary J C Lawrence
- CGDC, a summary Marian Griffith
- CGDC, a summary J C Lawrence
- CGDC, a summary Marian Griffith
- CGDC, a summary Jon A. Lambert
- CGDC, a summary J C Lawrence
- CGDC, a summary J C Lawrence
- CGDC, a summary J C Lawrence
- CGDC, a summary Adam Wiggins
- CGDC, a summary Jon A. Lambert
- CGDC, a summary Orion Henry
- MUD mentation system Matthew R. Sheahan
- How to handle log-outs in a totally dynamic world. Ben Greear
- How to handle log-outs in a totally dynamic world. John Bertoglio
- How to handle log-outs in a totally dynamic world. Ben Greear
- How to handle log-outs in a totally dynamic world. Dan Shiovitz
- How to handle log-outs in a totally dynamic world. Ben Greear
- How to handle log-outs in a totally dynamic world. Adam Wiggins
- How to handle log-outs in a totally dynamic world. Vadim Tkachenko
- How to handle log-outs in a totally dynamic world. Richard Woolcock
- How to handle log-outs in a totally dynamic world. Ben Greear
- How to handle log-outs in a totally dynamic world. Dan Shiovitz
- How to handle log-outs in a totally dynamic world. J C Lawrence
- On tanks... J C Lawrence
- On tanks... Ling
- More on LetsSystems J C Lawrence
- Attributes: Sanity Holly Sommer
- Attributes: Sanity Travis S. Casey
- Attributes: Sanity Holly Sommer
- Attributes: Sanity Holly Sommer
- Attributes: Sanity Adam Wiggins
- Attributes: Sanity Travis S. Casey
- Attributes: Sanity Holly Sommer
- Attributes: Sanity Holly Sommer
- mudschools Marian Griffith
- mudschools Matt Chatterley
- Mudschool Ling
- Using HTML for a Mud character generator John Bertoglio
- Using HTML for a Mud character generator s001gmu@nova.wright.edu
- Using HTML for a Mud character generator John Bertoglio
- Using HTML for a Mud character generator Holly Sommer
- Using HTML for a Mud character generator John Bertoglio
- Using HTML for a Mud character generator s001gmu@nova.wright.edu
- Using HTML for a Mud character generator Vadim Tkachenko
- Using HTML for a Mud character generator John Bertoglio
- Using HTML for a Mud character generator J C Lawrence
- Using HTML for a Mud character generator Vadim Tkachenko
- Using HTML for a Mud character generator John Bertoglio
- Using HTML for a Mud character generator Robert Woods
- Leaving characters in play Joel Kelso
- Leaving characters in play Ben Greear
- Leaving characters in play John Bertoglio
- Leaving characters in play Adam Wiggins
- Leaving characters in play J C Lawrence
- Leaving characters in play John Bertoglio
- Leaving characters in play Travis S. Casey
- Leaving characters in play Adam Wiggins
- Leaving characters in play John Bertoglio
- Leaving characters in play J C Lawrence
- Leaving characters in play J C Lawrence
- Leaving characters in play Travis S. Casey
- Leaving characters in play J C Lawrence
- Leaving characters in play D. B. Brown
- Leaving characters in play Travis S. Casey
- Leaving characters in play Adam Wiggins
- Leaving characters in play Jon A. Lambert
- Leaving characters in play s001gmu@nova.wright.edu
- Leaving characters in play Ben Greear
- Request "unsubscribe calvin@orinconhi.com mud-dev" Petidomo Mailing List Server
- Natural Language Processing (NLP) Shawn Halpenny
- Is There a There in Cyberspace? J C Lawrence
- Is There a There in Cyberspace? Jon A. Lambert
- Is There a There in Cyberspace? J C Lawrence
- [OT] Web Pages Jon A. Lambert
- AR Mining System John Bertoglio
- AR Mining System Oliver Jowett
- AR Mining System John Bertoglio
- mudschools Mike Sellers
- Using HTML for a Mud character generator Travis S. Casey
- Character creation, was: Mudschool Richard Woolcock
- Character creation, was: Mudschool Jon A. Lambert
- Onchat -- Java based chat room. J C Lawrence
- A short introduction of a (quite) long-time lurker Per Vognsen
- [MUD-Dev]World Size and The "Hot House" Factor Was PK and my "Mobless MUD" idea John Bertoglio
- mudschools jacob langthorn
- world concept jacob langthorn
- world concept Jo Dillon
- world concept J C Lawrence
- world concept Holly Sommer
- world concept jacob langthorn
- OT: Java multithreading performance Vadim Tkachenko
- OT: Java multithreading performance Ben Greear
- OT: Java multithreading performance Vadim Tkachenko
- OT: Java multithreading performance Chris Gray
- OT: Java multithreading performance Vadim Tkachenko
- OT: Java multithreading performance Chris Gray
- OT: Java multithreading performance Vadim Tkachenko
- OT: Java multithreading performance Chris Gray
- OT: Java multithreading performance Ben Greear
- OT: Java multithreading performance Jon A. Lambert
- OT: Java multithreading performance Chris Gray
- OT: Java multithreading performance Vadim Tkachenko
- OT: Java multithreading performance J C Lawrence
- META: Lost messages J C Lawrence
- Titanic's demise (was MURKLE: Wot it is) Mike Sellers
- Titanic's demise (was MURKLE: Wot it is) Koster, Raph
- mudschools jacob langthorn
- mudschools Marian Griffith
- mudschools Mike Sellers
- mudschools Marian Griffith
- mudschools Robert Woods
- mudschools Mike Sellers
- mudschools Robert Woods
- mudschools Robert Woods
- mudschools Caliban Tiresias Darklock
- MUD Schools Adam Casbarian
- MUD Schools Chris Lloyd
- MUD Schools Jon Lambert
- Combat Was Leaving characters in play Orion Henry
- Combat Was Leaving characters in play Oliver Jowett
- Combat Was Leaving characters in play Orion Henry
- Combat Was Leaving characters in play Oliver Jowett
- Combat Was Leaving characters in play D. B. Brown
- Combat Was Leaving characters in play Orion Henry
- Combat Was Leaving characters in play Adam Wiggins
- Combat Was Leaving characters in play J C Lawrence
- Combat Was Leaving characters in play Orion Henry
- Combat Was Leaving characters in play Adam Wiggins
- Combat Was Leaving characters in play Travis S. Casey
- Combat Was Leaving characters in play Adam Wiggins
- Combat Was Leaving characters in play Travis S. Casey
- Combat Was Leaving characters in play Adam Wiggins
- Bad Game Designer, No Twinkie! -- By Ernest Adams J C Lawrence
- Bad Game Designer, No Twinkie! -- By Ernest Adams T. Alexander Popiel
- Bad Game Designer, No Twinkie! -- By Ernest Adams J C Lawrence
- Bad Game Designer, No Twinkie! -- By Ernest Adams John Bertoglio
- Bad Game Designer, No Twinkie! -- By Ernest Adams Caliban Tiresias Darklock
- Bad Game Designer, No Twinkie! -- By Ernest Adams John Bertoglio
- Bad Game Designer, No Twinkie! -- By Ernest Ada ms Koster, Raph
- Bad Game Designer, No Twinkie! -- By Ernest Adams Caliban Tiresias Darklock
- Bad Game Designer, No Twinkie! -- By ErnestAdam s Koster, Raph
- Bad Game Designer, No Twinkie! -- By Ernest Ada ms J C Lawrence
- Bad Game Designer, No Twinkie! -- By Ernest Adams J C Lawrence
- Bad Game Designer, No Twinkie! -- By Ernest Adams John Bertoglio
- Java multithreading test source Vadim Tkachenko
- Java multithreading test source J C Lawrence
- Java multithreading test source Vadim Tkachenko
- Java multithreading test source Ben Greear
- Java multithreading test source Vadim Tkachenko
- Java multithreading test source Chris Gray
- Mud Tales John Bertoglio
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Ling
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Ling
- Nested coorindate space model Michael Hohensee
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Michael Hohensee
- Nested coorindate space model Jason Goodwin
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Michael Hohensee
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Benjamin D. Wiechel
- Nested coorindate space model J C Lawrence
- Nested coorindate space model Michael Hohensee
- Now For Something Completely Different: PK with style John Bertoglio
- Sex in Games -- ya gotta, um, yeah J C Lawrence
- Combat in the Abandoned Realms John Bertoglio
- A Metaphysics System s001gmu@nova.wright.edu
- META: New list features J C Lawrence
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Mike Sellers
- OT: Java multithreading test source Ben Greear
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Ben Greear
- OT: Java multithreading test source John Bertoglio
- OT: Java multithreading test source Vadim Tkachenko
- OT: Java multithreading test source Jon A. Lambert
- OT: Java multithreading test source Ben Greear
- Plug: Got my java client to work using the java-plugin. Ben Greear
- UO's rep system, was: CGDC Koster, Raph
- UO's rep system, was: CGDC J C Lawrence
- BIAP Chat/Chat Pro (fwd) Nathan F Yospe
- BIAP Chat/Chat Pro (fwd) Holly Sommer
- Tutorial for Multi-User Environments Niklas Elmqvist
- Tutorial for Multi-User Environments Niklas Elmqvist
- skill system Andrew C.M. McClintock
- skill system Jo Dillon
- skill system Andrew C.M. McClintock
- skill system Adam Wiggins
- skill system Marian Griffith
- skill system J C Lawrence
- skill system Jon A. Lambert
- skill system John Bertoglio
- skill system J C Lawrence
On Thu, 4 Jun 1998 01:18:32 -0700
John Bertoglio<alexb@internetcds.com> wrote:
> From: J C Lawrence <claw@under.engr.sgi.com>
>> On Thu, 28 May 1998 08:11:12 -0400 Andrew C M
>> McClintock<andrewm@tiger.hsc.edu> wrote:
>> The following really isn't in response to your post directly, just
>> me maundering about the area and noting things I stumble across:
I seem to be doing this a lot lately.
>> My general view of game features is that they must do one of three
>> things:
>>
>> 1) Provide a game-world goal for players to achieve.
>>
>> 2) Provide a game-world problem for players to solve.
>>
>> 3) Solve a game-world problem for players.
>>
>> This is based on the definition of a game as being comprised of
>> goals, barriers, and freedoms.
> Before I respond to the post, I think it is necessary to narrow the
> definition of skills and examine the other elements at work
> here. Much of what goes into a world building system is designed to
> answer one simple question: "If I try to do this will I be
> sucessful?".
Agreed. This was one of the brunts of my text. It actually is a
curious form of interface transparency, and utterly vital. Users
must, at some level, be able to predict the likely effects and results
of their actions.
Too much prediction and you have no game (excess freedom, not enough
barriers). Too little prediction, and you have no game (excessive
barriers, few freedoms).
> Specific skills are just a part of this equation. I
> would suggest that there are several elements which affect a
> character's ability to accomplish goals in a game world. These are
> often found in paper RPG systems.
Most of what you write following this I have no problem with, or much
comment on. It is (attributes/talents/skills) however one particular
model among a great many possibilities. For instance my model is
moderately different: skills/probability/attributes, with my concept
of probability fields only partially mapping to your concept of
talents (FWIW I have no concept or model equivalent to talents,
and instead debase the entire area into what you call attributes).
Curiously enough however my probability fields seem reasonably close
to what you seem to be doing with "quirks and flaws", except that I go
positive and negative.
> Skills: Skills represent a more formal approach to problem
> solving. I do not have a skill in the C programming language. I have
> the attributes required (I think), I have the talent (I can program
> in other languages and learn new things quickly), I even have
> related skills...but I really couldn't (at this moment) compile a 20
> line program with any chance it would run. No skill. Leave me alone
> in a room with a book and a compiler, I will develop some ability
> with C. I am still not a C programmer. If given the task: "Write a
> program for this embedded controller in C.", I will probably fail at
> this point. If the task was "Write a program which will print 'Hello
> World' to the console", I could probably succeed. Of course, I might
> have been able to guess my way to success as well without any study
> given the ease of the task. Given enough study and practical
> application, I could at some point raise my head up high and say I
> am a C programmer. A some point (in game terms), my skill level
> could reach a point where virtually any task was possible. However,
> doing that would cause my growth in other areas to stop and would
> require resources (cases of Diet Coke). That is why many people
> with a 456 level C programming skill have a .4 skill level in
> general social behavior. Perhaps leveling off at about 87 would have
> been a better idea.
You appear to be assuming a flat (or at least linear) skill model, as
vs a tree or a web. Have you read Legend's skill tree document?
Think drops of ink: skills bleed over into other skills whicha re in
turn variations of and reflections of other skills. Little exists in
isolation.
>> Skill webs primarily provide problems for players, especially as
>> contrssted to their prior simplistic model of levels where skills
>> came automatically with level progress.
>>
>> The primary problem is in gaining the necessary skills, a possible
>> secondary problem is in maintaining the required skill sets for a
>> particular play style. A presumably unintentional secondary
>> problem is in determining what skills sets are required for a
>> particular problem or play style.
> The creation of player archtypes which can be controlled by new and
> old players will give enough insight into the process. The skill set
> possesed by the npc character is exposed to its controler. Note that
> the specific numbers for success are not exposed. You take a skilled
> fencer into battle. You discover this guy kick butt with multiple,
> lightly armored opponents. You examine his STR and DEX, see he has
> a talent in Combat Arts. You notice he has a minor talent in
> Acrobatics and Athletics. You see basic combat skills, light armor
> wearing and a mastery of the foil and eppe...etc. Now, you know from
> running this guy that he is a good fighter. You don't know how well
> he would do trying to brew a vat of beer, since you don't see any
> grounding in specific skills or talents. If you try, you will
> probably fail.
Interesting idea, but one which requires exposing both the fact of,
and the structure of the skill system. I'm rather well convinced that
that is a Bad Idea for the reasons I dicussed later.
>> This last point seems the nastiest, and comes in two flavours:
>>
>> 1) Should the fact of, or the structure of the skill web be exposed
>> to players?
> If the nature of the skill web is stored in a mathmatical matrix in
> the server, it will become common knowledge whether directly exposed
> or not.
True. However we are all well familiar with the spread of myths and
contorted understandings on MUDs. Players come up with the most
curious concepts for how things work or accomplished internally
(something that should be encouraged?).
> There are all kinds of cool things you can do to mask it,
> however. Example: Everybody "knows" that the monastary on the
> mountain will take one character at a time to train as a Quack-Foo
> fighter (a partically potent form of martial arts). Everybody
> "knows" the character *must* have a grounding in the basic Foo
> fighting skill (which is rare but still easier to come by). What
> nobody "knows" except the server is that once in a while a person
> fitting the right attribute/talent profile will be invited to
> study. This might be controled by the phases of the moon, the
> calendar of feast days, a lack of a current student or just dumb
> luck.
Precisely.
>> 2) If it is exposed, how do players determine what skills are
>> required?
> Again, the word will get out. Some things are obvious. If the
> command [SEARCH FOR WATER] is understood, players will try it. If
> the skill of Water Witching is learnable, one would assume this
> would make ones chances of finding a suitable well higher.
You are assuming that a player has an ability to train in a stated
skill or skill area. I'm not. I map skill improvements directly to
use, observation, and education. There is no equivalent of a TRAIN
command, or a LEARN SKILL command. Education is by side-effect, and
is opaque to the users. If they read a book and see text on their
screen describing, say, water dowsing, I bump up with water dowsing
skills and possibly their water probability fields, Similarly if they
go about dowsing, or watch others going about dowsing. I have no
concept for "tell my character to go learn about XXX".
>> Making the answers to #A vague (large granularity) dones't solve
>> the problem, it mrely makes the answers unreliable and largely
>> useless.
> Make them accurate but only within the players ability to
> perceive. This mean that, in general, by the time a fighter can
> accurately assess his opponents, he won't need to in most
> cases. Opponent identification is an action. It is governed by
> attributes, talents and specific skills. An ace swordman might
> notice a potential opponent had the moves of an expert swordsman (I
> don't know how, ask a swordsman) so would be reported an estimate of
> the sword skill. Most people would have a reasonable estimate of a
> persons strength, but would miss the knuckle scarring of an expert
> brawler...etc.
I statistics reports relatively, but for yourself (ie your character),
and for the other characters you query. Loosely, any statistic is
relative to a weighted average of all the other instances of that
statistic you have met in the recent past, with a heavier weight given
to exceptional values in the more distant past. The cannonical joke
of which is:
> stats
Strength: 150
> l
Bubba picks up a huge boulder with one hand and crushes it to
sand on his head.
> stats
Strength: 25
> l
A leaf flutters off the tree above and smashes Boffo to the ground.
Boffo is stuck under the leaf and can't move.
> stats
Strength: 65
Nothing changed except for his perception of strength.
The attempt is to model a form of self-image as weighted against
perception. Most delightfully stat reports react to illusions as if
they were real. The leaf above may well have been illusory, or Boffo
may well have been play-acting to purposefully delude your
perceptions.
>> q) What are my chances of being able to accomplish XXX?
> You guess or ask. As before, by the time the answer the world gives
> you is accurate, you will already know the answer because of
> experience.
BTW: This was SHADE's approach. As you gained levels, various
actions succeeded more often. All actions were possible by all levels
however (they added newbie exclusions later). Example:
All players could SUMMON other players, however the probability of
your SUMMON command succeeding was a function of your level. A newbie
character might hit success one time in 30. A higher level might
succeed at 70% of his summons.
That was the only exposure of the level gains (other than increased HP
and strength).
>> IV) What are the impacts on my game play and game style for
>> maintaining those skills at those levels (eg spend 90% of time
>> maintaing skill sets for 10% "play" time)?
> Skill mainntence should not be an major issue. Skill improvement
> should be. Finding ways (and places and teachers and situations )
> to improve skills should be important.
This of course assumes that there are always skills that can be
improved in a character (with presumably minimal loss or effect in
other skills), and that the fact of other available skills, or even
what skills the character does or does not have is exposed.
--
J C Lawrence Internet: claw@null.net
(Contractor) Internet: coder@ibm.net
---------(*) Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - skill system s001gmu@nova.wright.edu
- skill system Adam Wiggins
- skill system Katrina McClelan
- skill system Richard Woolcock
- skill system Koster, Raph
- skill system John Bertoglio
- skill system Adam Wiggins
- skill system Mike Sellers
- skill system Richard Woolcock
- skill system Adam Wiggins
- skill system Richard Woolcock
- skill system Katrina McClelan
- skill system Adam Wiggins
- skill system Richard Woolcock
- skill system Katrina McClelan
- skill system Adam Wiggins
- skill system Dan Shiovitz
- skill system Adam Wiggins
- skill system Richard Woolcock
- skill system Adam Wiggins
- skill system Richard Woolcock
- skill system J C Lawrence
- skill system s001gmu@nova.wright.edu
- skill system J C Lawrence
- skill system John Bertoglio
- skill system J C Lawrence