Moving to Wordpress for better image options.
http://tinmantex.wordpress.com/
Wednesday, March 9, 2011
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.
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.
Subscribe to:
Posts (Atom)