Sunday, November 9, 2008

I'll Atomize your face.

I've been interested in Dan Cooks Skill Atoms concept since he started posting about them, but it was only until my current mod that I thought that (retroactively) trying it out would be beneficial.

Actually I initially wrote this up as a email to Dan, but one of his recent posts prompts me to throw it into the light, as well as start up a blog so I don't dump all my crap into his comments.
So here it is:

A brief background on me for context of following:
I'm 28, playing games a fair while as you might imagine, but only recently started modding games, still rather casual in my designing but recently been having a better look/think into design, helped by articles such as Dancs.

Anyway, since I'm moving on to work on the next version of the mod working away at a few fixes and features (some helpfully informed by aspect brought up while building the Skill Tree diagram) I though I'd at least pass on what I have so far, along with a few musings I scratched down while working on it.
So, it's an incomplete tree of my current version, ie incomplete design.
My mod leans heavily on it's parent game. Quake Wars is the most recent refinement of objective based team multiplayer by id software and splash damage, that in itself should make the tree interesting for some, because although my mod changes the higher goals quite drastically it's still based around the well worked fps core.
Other points of interest being the Cooperative/team based skills, while opponents aren't diagrammed I do have a few thoughts about them in relation to skill trees in my following notes.

Here's a 15 minute play through of a recent version of my mod, It's annotated to explain most aspects of it:



The skill tree diagram is still rough, I've bashed away at it only over a couple of nights last week. It's rather ugly hashed up in a uml program, because it was the easiest diagramming tool I had at hand. A lot of Skill Atoms still have to have their details completed, still have to chain most up.
But it has been nice in pinning down exactly what feedback I'm giving to the player, and where I should improve that.

The diagram - open the link
Click Download -> Download Photo
Then open in an image viewer.


You'll see a rough out of the games tokens near the top, the rest being the skill tree.

There's a few areas causing me a bit of head scratching.
Like when there's many variables that effect the outcome of a skill (ie different states of the token the player is using the skill on, most common is many different states prevent player from using skill aka fail), I'm still not sure how to clearly document that as you will have to list all the rules, as well as the different outcomes for the different rules.
And also chaining, I could just chain the skills in the way that they 'should be taught', it's just that my current design, being a multiplayer, drop-in game currently doesn't have any method to reinforce order of learning of the skills.


Now my rough notes/braindump:
A goal is a desirable outcome that the player perceives they can achieve. Ideally a new skill with many branches, or a resource for the player to manage, or finally some new content.

Expanding the skills/paths to achieve a goal can be good, however must be managed.
A player will likely keep using lowest cost path through their skill tree to a goal even with multiple paths.
So the solution is to add situations where those skills are countered - something to cause the players skill attempt to fail (naturally giving clear feedback on what it is).
Upon facing the set back the player will re-evaluate their skills and try something new - re plan, again, common decision making.
Ideally the player can think of an alternate route around the countered skill, or knows another skill to remove the cause of the counter (the rock paper scissors scenario).
Opponents are agents that dynamically counter the player, ie they make decisions on the current state of the game on what Skills to use to counter the player.

Frustration:
A player will become frustrated when they have attempted all their perceived skills and still not achieved their goal.
This is may be caused by some skills not being considered - poor feedback may have prevented them from trying an existing skill, or learning it in the first place.
Another source is repeatedly failing an existing skill that they have used before but possibly not mastered. Often a matter of mis-pacing of challenge.

Boredom:
A player will grow bored with a game when they think they have achieved all the goals that matters to them, in a sufficiently optimal way, ie if there's enough variation in paths to the goal they may try again in a different way.


Length and breadth of the skill tree increases length of game, as does goals (usually content).
Dynamics add to replayability of game:
Randomisation of token states on new game
Opponents that can counter players as their skills increase.


Human Problem solving – It's messy, people will often 'lazy plan', choose a short part of their mental skill tree to try and replan on success or failure. More complete information improves the initial path choices, so there'll be a lot less error than trial.
Truly mastered skills often have been mentally automatized, they don't need to consciously think about them or their costs in order to plan with them, they may work backwards, considering skills more advance skill several steps down a branch before or without considering the skills leading to it.

Emergent. Players will try different combinations of skills and variations within the skills (time/space being the most common 'widest' variables for skills), to create new ones. Or they already probably know many skills from real life that apply.
Not all emergence is good, if a new skill is learned that creates a low cost path, since it's outside of your considered design it won't be countered.

Mastery – Not just how to use skill but the effect(s)/costs of success and failure.

Tension also comes from predicting failure/restriction of skills.
Difficulty/pressure is the amount and length of counters to players skills.
Players are less likely to learn new skills under pressure, the are more likely to miss cues or be too engaged to consider skills they don't think related.

Teammates and opponents are both types of agents within the game, they often can manipulate enough of the tokens in the game to change the game state in a significant way.
They are also out of the direct control of the player.
This means the player will strive to understand what skills the agents are capable of so they can consider them in their decision making.

In the case of opponents it's the case of learning what skills of the player they can counter.
In the case of allies it's a case of learning what skills they have that the player doesn't.

Players won't have the same mental skill tree as others.
The player will try and recognise allies with a more complete skill tree (better than me/better at the game/more skilled) and mark them as potential teachers, likewise recognising 'less skilled' players as potential students.
This can be a goal in itself - raising the skills of an ally that benefit the player.

Not under direct control - this is where communication comes in, it is the main channel a player has to exercise the interpersonal skills they have, to persuade an ally to use the skills they have in a way that the player wants.

A lot of this can fray off into the complexity of real world interaction, what most games have is a focus via goals and skills that let players short-cut things.
Players can more quickly recognise if other players are using the same tokens as they are, and thus have a similar skill tree to draw from.

You may have a verb that applies to many different tokens, if the outcomes are significantly different they may need be handled as skills, all the skills will combine into the general skill of that verb (as the actions are most often the same). A player will likely learn the general case pretty soon after only trying a couple of different specific skills, but it's not completely mastered until the player has explored, which of course isn't something that the player is likely to know, so they'll keep trying it in situations that seem similar to the previous successful outcomes.
The thing here is to make sure your general skill has some constancy to outcomes, having completely random outcomes to a skill is obviously no good, but there's a divergence point where a player wouldn't consider using the skill because they don't think it applies.

Simply diagramming Skill Trees helps the designer see what feedback they are giving the players whether they succeeded or failed.
Bringing the model into the game to measure players progress:
May allow for more dynamic, informed feedback, moving from subtle hints to more direct methods to make sure they understand.
It may also allow for more fine tuned opponents.
Skills may atrophy between play sessions? I'd guess more so partially mastered skills, but most often the problem of coming back into a game after a long is reasserting long term goals.

8 comments:

Daniel Cook said...

That is a thing of beauty! Is there a more readable version of the tree that you could post?

Out of curiosity, were there any specific spots in the game where the act of diagramming resulted in a crisp identification of a new problem?

From what you've covered, creating the skill tree seems to have given you a better understanding of the dynamics of your game. Is that a fair assessment?

Good work!
Danc.

Tex said...

Spent a chunk of the day being entertained by my 4 year old niece playing Legend of Zelda, it probably deserves a post in itself :)

Danc,
Yeah, depending on your browser the image will be only sized to the window frame, not the full image resolution.
You can try downloading the image and view it in an image viewer.
If you've already tried that I'll send you the full resolution image via email, this one is about 60% of the output from the diagram tool, simply because all the image hosting sites where just plain choking on it.

One area it helped was with each Skill being broken down it was clearer to document/get a handle on the feedback needed.
In a couple of places I was already aware of the general problems, but as said breaking them into atoms made it crystal.

You can see the Use pliers skill is the only tool that uses a finite resource, I'll probably expand on this point in a new post as it digresses a bit into a lot of related problems.

I mostly dumped a whole bunch of skill atoms into the diagram, mainly just as labels, as I started working on the feedback information for them I saw where I should split some, and creating skills for the specific applications combining to more general was good too.
Then further creation/editing when I tried to chain some.
There's a few links missing simply to prevent clutter where a skill is spread out from what it's linked to.

While working through the diagram I was also refreshing myself with your game chemistry article, and also Ralph Kosters game grammar, and that's when I started throwing into my notes various digested ideas.
When I started considering the multiplayer/coop/opponent aspects thinking about them from a skill tree perspective was pretty enlightening.
I also was reading this at the time.

Still further thought/work through needed for that though.
In terms of my mod, even though it's not clearly diagrammed yet thinking through it has brought to the fore how lacking the opponents for the human team are currently in terms of a broad tree of counters.

So, moving ahead I can see how using the skill atom/tree diagram in continuing my design past what's currently implemented will help me keep things in easier steps (broken down to skill atoms) and clear (feedback on the atoms).
Also building better cooperation and opposition between players/agents.

Apart from opponents, not so much clarity the dynamics of the game yet, though that's something to definitely something to work on, and skill trees definitely gives me an interesting framework to work with.

You can already see a bit of where the movement skills apply on to the play space, naturally topology of the tokens is an important aspect to consider for a design.
The other biggie of course being time

I'll probably first work on documenting the variables within each token (in the token diagram), then seeing how they'll inform the skill tree.

Tex said...

Sorry Raph, I let an l slip in there.

Vincent said...

Hey Tex, I'm also a big fan of Danc's Skill Atoms. I'm also have trouble reading the detail on your tree. It looks like the original is in Visio, I could make a PDF for easy readability, if you wouldn't mind emailing a copy of the original doc.

Awesome work!
Vincent

Daniel Cook said...

Aye, a PDF of the chart would be wonderful. Even when I save it out full sized, the text is fuzzy. Let me know...I'd love to link to this page!

take care
Danc.
(danc [at] lostgarden [dot] com)

Tex said...

Ah sorry, the uploaded must have downsized the rez. I though I had checked it after I uploaded it, but I must of looked at the wrong file heh.
The diagram program I used is called Dia, it has an export to visio, but I don't know how accurate that is.
Even then I don't know how I'd host it, doesn't seem blogger provides any file space.

Tex said...

Ok, got it sorted, hit the image link, then click download button.

Dan said...

FYI, if you're reading this on Blogger and can't get a hi-res version of the image, note that Tex has moved this blog to Wordpress. Here's this post there. http://tinmantex.wordpress.com/2008/11/09/ill-atomize-your-face/