Tin Man Tex's Slap Dang Blog

In a few words, I don't know what this site is about.

Category Archives: Skill Atom

Brink of the Atomic Age

If only, but I’ll get there myself, it just may take a while.

A much delayed return

Writing this post was what prompted me to post again, which doesn’t make sense, it started as an email to my brother, which started as a discussion on what I had been doing. (I also realise my previous post started as an email, I also realise I should start the post because I’ve likely bored you).

A history of virtual violence

I’m kind of an old-hand when it comes to PC multiplayer FPS, though maybe not the oldest, and my route is partially marred by late adoption of some games.

My first was Quake 1, four player LAN Deathmatch with friends, but Quake 2 was when I threw myself into regular online multiplayer. Quake 2 Capture the Flag introduced me to the joys of team based multiplayer with an objective.

Team Fortress Classic grabbed me and showed me what class based gameplay could add (I missed TF1, though I could say Weapons Factory for Q2 was my TF introduction) by adding restrictions and differences between player abilities teamplay was enhanced by classes bolstering the weaknesses of others. And also a few different objective gametypes.

A dalliance with Counterstrike showed me how a few rules and different style of gunplay could change things, and it threw in a few different types of objectives like bomb planting/defusal, hostage rescue.

Tribes showed me different movement options, a more open playspace, and more flexible class/loadout options.

Return to Castle Wolfenstein MP hit the spot with me, it condensed and refined classes in comparison to TF, adding more team supporting actions, and integrating the classes into chained objectives. These were pretty much a role call of many of other games single objectives, however with specific classes able to do certain objectives it further increased the importance of players playing those classes, and the need to support them.

The sequel Enemy Territory refined things, adding an inter-campaign ability progression system.

I only briefly touched the Battlefield series, which provided an array of vehicles, a much larger playspace and a gametype that drove conflict across it.

The Call of Duty series didn’t really advance much, seeming to focus on polishing what it had to a blinding sheen, it gradually expanded a few movement options, a customisable loadout/abilities system with progressive unlocking, but stuck to the same simple gametypes.

Quake Wars built upon the Enemy Territory gameplay, adding vehicles, and deployables to the infantry core of its predecessors in a strengths/weaknesses/counters arrangement. There was a larger playspace to make use of these additions, but still focussed by chained objectives.

Where could this trip through multiplayer team based fps leading? A new game by Splash Damage in the Enemy Territory gameplay lineage called Brink. And that I’m kinda interested, to put it mildly. And to put it mildly is grossly understating it.

Brink of an overused pun

The game isn’t out yet but there’s a helpful compendium of info created by a fan based on pretty much everything the devs have said about it in interviews/articles/forums.

A recent discussion on Splash Damage’s community forum about team-deathmatch and single-objective game modes that most console FPS have vs the chained objectives of ET line prompted me to try what I’d been meaning to do for a while, sketch out the game design of Brink, and hopefully exercise my design notation methodologies a bit further, and get a better understanding of the game both as someone who is interested in the gameplay as a (future) player and as an aspiring designer.

I had my previous diagram from my ETQW mod Dusk as a starter, I’ll talk a bit about the comparison/changes in the games design in comparison to ETQW later, apart from that, sectioning things and colour coding makes it much nicer to get a grip on things.

In the diagram I’ve got several different diagram types:

It may be better to save these images and open them in something that can variable zoom (the default windows image viewer for example).

First up is Token/Playspace view – Token is a term taken from board game design and basically means an object the player can manipulate and the game rules apply to.
As for playspace, I’m not sure where I took the term from (possibly Dan Cook, though he probably uses it differently), it’s basically the ‘board’ or environment the game/tokens are played on.

To the right of that is a game rules diagram, this is not so developed, basically I was sketching (that word again) out the _game_ game rules, because they don’t fit (or do they?) into the main diagram:

Skill Tree, the objects here are ‘Skill Atoms’ to use Dan Cooks term (he writes a blog and I really dig his articles), or I just call them Skills or sometimes actions, though maybe I shouldn’t, to keep things clear -_-
You may need a bit more of a swot up.

At the lower-level/top of diagram skills are direct actions the player can perform, they combine and chain into further skills, and chain into the winning conditions of the game.

It’s useful when you understand what a skill is – something the player must learn to play the game – you can notate what feedback for success/failure you give the player trying to use that skill.


An addition/notation I added beyond what Dan Cook described is the ‘Counter’ to that skill.
The player’s opponent(s) in a game (sometimes the game itself) have their own skills that they can play that impact on the players use of a skill.
A very simple example is a fighting game – one guy punches the other who blocks it.
Or in design terms:
Player plays an attack skill against the opponent token, the opponent plays a block skill (of their token) which causes the attack to fail.

I believe counters are what provide the main challenge of a game, and in combination with a wide enough skill tree – where the player has lots of skills they can play to achieve their goals (the main which being to win the game of course) – counters restrict or shut down skills so the player can’t just learn/optimise their skill use to the best/quickest path and play that each time.

It ties into difficulty and pressure – ie the pacing/frequency, severity of counters to the player’s skill.
It’s useful when considering AI – basically an AI (actually any opponent, if I’m generalising) becomes boring when it can no longer counter the player effectively.

You may remember me waffling on about an AI technique called a Behaviour Tree I was poking away at, it’s turns out pretty close to a skill tree except it’s built top-down, and of course has a lot of decision-making nodes as well as the Actions/skills.

My foray into AI is probably needs a post itself.

I still need to figure out how to diagram counters better than just notation. Then again it’s the same issue preventing me from full diagram chaining with the nomral skills, it’s falling into graphing territory and the solution is likely a better, more dynamic diagramming tool.

Brink of evolution we see, hmmm?

Damnit Yoda!

As mentioned, I used my Dusk mod diagram [huge image] as a base, since the mod is based on Enemy Territory Quake Wars and Brink is the spiritual successor to this gameplay.
Though it’s more a return to the smaller scale, infantry only Wolfenstein Enemy Territory, no vehicles, large-scale strikes or variety of deployables.

I think 8v8 will be very cosy, any less players than that and much greater preassure is put on each player, and on the other end greater ammount of player reduces the importance (agency? if I want to borrow another designer term) of each player.

Apart from noticing the large amount of skills that were related to those aspects from my existing diagram, one change is the simplification of weapon selection. Quake Wars did have a context based tool selection for the use key, but you could still manually select tools along with weapons in classic fps weapon cycle fashion.

Brink relies more on the context use button, that pulls out the required tool (if any) when used on an object that supports it, in some cases tools have been simplified from use-anywhere to this, example being health and ammo packs used to be dropped as physical entities where anyone could use them by running over them, now the action has the pack being thrown directly to a receiving player.

While in general it helps streamline things, there’s some kind of disconnect there that I can’t quite describe at the moment. I do know that for Dusk, adding even more skill related to the use of items was satisfying (and fitting for the gameplay I wanted).

The weapon switch button now switches between primary and secondary weapons. Which I suppose is good enough, and should get more use from what I’ve understood of the weapon loadout system.

And finally 3 buttons (or dpad on a control pad) for ‘active abilities’, ie the remaining tools that are still use-anywhere, like mines/turret. I think this was partly driven by gamepad interface issues, but it may be a case where 3 active/selectable use-anywhere tools is a sweet spot, who knows, SD possibly.

Grenades have been shifted out to a separate button ala most current fps, prior ET games it was just another selectable item. There’s other changes to grenades to help smooth over issues with current implementations, which prompts discussion about SDs attempts at explosive ‘spam’ reduction. Because dying isn’t that fun, traditional explosives implementations tend to be high damage and/or area of effect (aka splash damage, where the company took its name from).
As the amount of explosions increase the difficulty of coming out alive drastically reduces.

Nadespam, the curse of many a game

Team Fortress 2 completely removed grenades that it had established in prior versions.
Brink actually increases the types of nades from a single type to something more in line with classic TF (or you could say more in line with CoD).

Grenades in Brink are on a cooldown, which helps decrease the rate of spam, they no longer have an ammo count however, I’m not sure of the decision on that, while it keeps their use constant, it looses the opportunity to make the soldiers ammo restock ability more useful/desired.

All explosives in Brink will at most cause incapacitation, no longer can a player go from living to killed, it’s alway to the intermediate incapacitation state, which provides the player the chance to be revived by a medic.

Seeing stars, smelling roses

Another downed state has been added – ‘knocked-down’, this may be caused by being caught at the edges of an explosion. The player can’t move but can still fire (with reduced accuracy), but can get up again unaided.

Melee – another skill cribbed from other games, but expanded upon, melee is (thankfully) much less powerful than in other games, it causes knockdown instead, a melee on a knocked down player will kill them however. So this sets up a skill/opponent counter group.
Melee knocks down, they are vulnerable and can choose to shoot, or stand up. Likewise the opponent can close in to deliver a finishing blow, or to stand-off and shoot them.

Show me your moves

Movement, an important aspect of many game, has been expanded, there are added parkour moves, mantle, vault, wallhop, slide, I think I’ve described them mostly in the diagram.

It’s probably best to hear from the horses mouth directly on this though.

In general they are likely to expand the players options for navigating/interaction with the playspace vs prior games. Though it can be noted the CoD series has expanded it’s vaulting/mantling over versions.

Movement, in respect to the playspace is something else I should discuss at some point, a topic in itself. I’ve got a mind-dump note about it in the diagram. A topic in itself maybe.

An interesting addition is SMART – It’s a button that automates some of the above movement skills, the player still controls low-level move dir and aim. It essentially eases the entry-level for movement, however I think since it’s based on rigid game code players that master the manual movements will retain the edge.

I could go into an aside about the tech behind it, but that’s probably one more reason to do an AI post.

Brink of evol[wait you already did that one]

Another case of adding skills around an existing token (as is often mentioned as being a good game design thing to do) is for command posts. Command posts have been a feature of ET gameplay from the start, essential providing a sub-objective of a capturable respawn area, to the benefit of however captured it as they would be situated closer to the main objective. The counter was for the other team to recapture it.
I’m somewhat shaky on whether capturable command posts still provide spawns, due to a new element where it will provide some bonus (team wide health buff was an example given).

All command posts (including an initial, non recapturable one) now provide an in-game interface for weapon loadout and class selection. In prior games this was handled by a full screen limbo menu, part of this is due to streamlining/gamepad accessibility, and removal of one feature (you can no longer choose your spawn area), but it’s nice as it anchors the utility of the command post in the game.

Further cementing different class usefulness is a skill/ability for a player playing the engineer class to ‘upgrade’ the command post, for some (as yet unclear) team bonus, and also for an operative to ‘firewall’ an command post to increase the time it takes for the opposing team to recapture it (should they attempt to do so).

And talking about class differences,

Lets talk about class differences

The team based skills (color coded blue) – the now well established ammo and health handouts and revive, new skills include the engineer being able buff an allies weapon, and the soldier to act as a shield for an ally (which I just realised I hadn’t diagrammed), moving with the ally and taking damage in their stead.
I’m happy about that. Its surprising/disapointing how anemic the selection of player-to-ally skills has been for most suposedly team based multiplayer games.

Brink of madness[when will you stop?]

I’ll stop here or I’ll end up pretty much retyping the info compendium I leant most of this from, but at least I’ve got a few of my opinions/comparisons down.

[you said you’d stop, but still you’re progressing]

The progression system is something else I should go into at some point – in respect to how it likely aids learning of skills but that’s another deep topic.

Anyway, I’m not likely to advance the diagram much, though I may when the game comes out.

About those objectives

Oh and insight into the question that started me on this? Team-deathmatch or single objective gameplay? Remove all the skills colored pink. Now I know why I’m bored of those simple gametypes.
That’s being a bit harsh of course, there would be a couple of skills in the objective group even for a single objective gametype, and to be sure I could add a few skills related to team strategies that evolve around it, but then again I haven’t diagrammed such skills for ET/Brink gameplay either.

I’ll leave you with the full combined diagram:

There’s a few bonus diagrams:
Game rules is just a sketch, still trying to feel out what I intend with it.
The hud diagram is not up to date, and would probably be better served from an anotated screenshot.
Combat, is musings, partly from a half digested article on considerations/decisions during fps combat.
Resources (which possibly deserves to be shifted to tokens/playspace) is just that.

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 for Quake Wars that I thought (retroactively) trying it out would be beneficial.

Actually I initially wrote this up as an 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.

A mod called Dusk, and a Skill tree thereof

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 its parent game. Enemy Territory: 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.

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

Working as I go

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, the 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.
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.

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.

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


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.


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.


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.

A bigger and better game

Length and breadth of the skill tree increases length of game, as does goals (usually content).
Dynamics add to replayability of game:
randomization 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 to 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.


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.

Agents, agency?

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, and others

Players won’t have the same mental skill tree as others.
The player will try to 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.

Agents again, communication

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.

The general skill from specific skills and/or visa versa

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 tried all applications of the skill, 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.

Atropying skills?

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.

Why skill tree?

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.