When it comes to Chimborazo and character progression systems, I had to thread entirely new ground and come up with a completely innovative method to do progression. New ways to work with new things, from figuring out what would be subject of progression in the first place all the way to figuring out what I can use to trigger it. To put things in perspective, consider this: How many of the rpgs you know are classless? How many of those are levelless, too? From those, how many don’t use any metric dedicated to progression, like experience or meta currencies? We’re already in the single digit percentages of all ttrpgs, if we’re lucky to have anything other than 0 before the decimal point in the first place. All of this simply means that when it comes to progression for this kind of game, there was little to no existing design knowledge for me to spring off of.
Practice to improve
I don’t have a clever motivational quote for this section, but I swear it makes sense for the context of this article.
This is the core tenant of the progression mechanic and one of the main pillars the entire game is designed around. While it sounds obvious enough, it’s worth unpacking further. The main intention here is that you become better at what you do. Or, to phrase it more obviously – in order to improve in something, you have to do that thing. This ties directly into my main philosophy: making mechanics as associated as possible1. Alongside minimal tracking and faster gameplay, these three design pillars of the game have the most influence over the advancement system.
All that being said, what does that system cover anyway? The core of Chimborazo consists of three parts: stats, skills, and tags. Two of those are subject to progression – the gradual evolution of a character over time. Whether it’s vertical (power increase) or horizontal (power diversity), progression is one of the most vital parts of any game. Arguably – the most important one. So now the question becomes “What do we do for progression?”
This is where the problems begin. Not all of them hard or particularly different to overcome, but problems in the sense that they require solutions. Deliberate decisions have to be made here (rather than designing by default), and they better serve a purpose. For instance: which parts of the system do we want to subject to progression, and in what way?
For what it’s worth, the point here is not to (completely) re-invent the wheel. Do other games do stat increases? Yes. Do other games give you new skills over time? Of course. But the point is to examine why you want those things in your game, instead of assuming that you do. In my case, I think that stat increases (and decreases too, but “reverse progression” is something I’ll make another article on) are a great way to show how a character changes over time2. For skills, however, I want two things – getting new skills over time and upgrading your existing ones occasionally.
Acquiring more skills is, I hope, as obvious as it gets. New ways to interact are exactly what’s going to keep the gameplay fresh over the longer campaigns Chimborazo is intended to support, and players can get excited over working on a “build”, getting a cool combo of abilities, and overall making their character unique and making their game experience personal. Very rarely will you see an engaging game in which you end up with as many or fewer options than you started with (for a good reason) and this is very much true for mine as well.
Stat and skill improvements, however, have a different purpose altogether. The goal here is to showcase a character’s increasing mastery over an element of the game. Whether that be improving an aspect of themselves, or getting better at something they do, practice over time leads to better stats and stronger skills. This is the core idea of the progression system and the feeling I want to evoke the most. However I also want to hammer into players that it’s not easy and it takes time. Progression in this game is relatively slow. Skills are hard to upgrade and stats harder still. But working so much for something only makes it that much more intimate for your character and more rewarding for you as a player. The mechanics that handle this progression should feel almost cathartic and be all the more impactful for it.
So. For characters – over time – I want stats to go up, skills to get better, and to get more skills. Ideally due to practice and engaging with the fiction in an associated way. With the what part established, now the question becomes how to accomplish this? Since it’s essentially a reward mechanism, I need tangible break points that can be recognised by the game (and those playing it) so that it knows when to reward the character for things they are doing or have done. And it’s here that I get to the real crux of the issue at hand. How can the game check how the character is doing?
“Traditional” ttrpgs have it easy. They have very well defined little boxes in which they put characters, and they can do all sorts of things with those. Level up? Get new abilities from your class (that’s a box). Occasionally also get a stat increase because why not. When do you get new levels (that’s another box)? When you amass enough XP. Do things to get XP. Oh, and you better track that somewhere! Depending on your race (oh look, a box), you might do extra things, or different ones. You get the point already. However, despite my apprehension for many of those things, I want to point out that having boxes – and lots of them – is by no means a bad thing design-wise. Compartmentalisation is a very useful tool. Chimborazo has boxes too, just not the traditional ones, which is more or less the whole point of this article – I can’t use most of the accumulated design knowledge of existing rpgs because my game’s progression is trying to be as fluent as possible while traditional progression is based on very rigid systems like classes and levels.
Uh-oh! But Chimborazo is a classless and levelless game!3 Even if you amassed the XP, there are no such tangible boundaries to interact with and thresholds to cross. The GURPS method of just getting XP for stuff and then spending it like point buy doesn’t work either, because oh by the way, there’s also no XP in the game to begin with. In looking into the “tangible” things it does have, I found myself quickly shooting down one idea after the other for various reasons, some of which weren’t as well justified as others – in hindsight. But I didn’t just want to have progression mechanics, I wanted to have the perfect progression mechanics. And so, for a weirdly long time, the game actually existed more or less without any progression. I ran the playtest campaigns, characters were almost “handed out” new skills when it made sense narratively on a per case basis, but those skills didn’t get better and character stats didn’t increase. Meanwhile, I continued trying to solve the problem.
As I usually do whenever I’m stuck on anything, the first thing I do is try to re-frame the issue at hand by contextualising it in another way. The winning idea here was the following: regardless of how other games do progression, what does it mean in the first place? Well, like I alluded to earlier, in essence it’s a reward system for things the character has done. And in this moment, I started to realise that most games check whether a character has done something – anything – where as I wanted to check what that character had done (because of the driving philosophies outlined in the beginning). So, a game like D&D would ask you “Did you kill the monster? Here’s some XP. Do you have enough XP? Here’s a level. Do you have enough levels? Here’s a prestige class.” Meanwhile, Chimborazo would ask you “What did you do? Oh, that? Well, if you keep doing it, surely you’ll get better at it, I believe in you! Oh, you are getting better at it? Well, if you prove that you’re good enough at it, I’ll be convinced and never ask you again.”
With this paradigm shift, I came to realise I don’t need neat little boxes to compartmentalise, because I want vertical progression to be rarer but far more personal and meaningful for the character. The current boxes of the stats and skills (if we were to call them that) are enough on their own by just existing, all they need for advancement is something to key off of. As it turns out – after thinking on the matter for a very long time – the aforementioned design pillars that guide the progression system, the core philosophies behind these mechanics, don’t actually leave too much choice in that regard. What they basically say is: to get better at something – do that thing; to learn new things – go and learn those things. Admittedly, this sounds equally obvious as it is redundant, however unpacking these statements under the context of the mechanics the game has leads to more useful and concrete answers. I’ll go in chronological order of how I did each of the three things needed for a complete progression system. Let’s get technical.
Acquiring new skills
Before going further, first I have to explain how skills “exist” in the first place. If you’re thinking about skills in the way D&D uses the word, stop. In Chimborazo, skills are everything characters do, all of their spells, attacks, passives, charisma, etc. Eventually this will be replaced with a link to the skill article. In the mean time, how are skills structured? Well, skills grow on skill trees, which have branches and several tiers.
Here’s a set of three very iconic skill trees. Yes, that is the skillset of the sorceress in Diablo 2. But it works as a familiar baseline example that puts people in a better state of mind to understand the concept. Overall, I doubt almost anyone will have a problem comprehending what a “skill tree” is, but it’s important to stop them from thinking about D&D’s ridiculous skill list (it’s mockingly called a “laundry list of skills” for a reason). Now, how to actually gain access to new skill trees and the skills therein.
This entire system is built on the concept of prerequisites, a.k.a. meeting certain conditions and/or passing certain thresholds. Once you do, you immediately gain access to the skill tree that requires them, which also involves access to the first tier of skills4 in it (they share the requirements of the tree as a whole, or perhaps the requirements of the tree are the requirements of the bottom tier skills – these are two ways to say the exact same thing). From then on, skills on higher tiers of the tree may (and almost always do) have additional requirements, which can vary. Look at the sorceress trees above. Each tier has a level requirement, but there are also dependency requirements (indicated via lines). Some skills require you to have the previous one from that “branch” of the tree, otherwise you can’t get it even if you meet the level requirement. Chimborazo doesn’t have levels, obviously, and the tiers are there more for framing and structural purposes. But what kind of requirements are there to begin with?
The two basic ones are education and training, representing the theoretical knowledge of and practical experience in some area, respectively. While there are plenty of exceptions to this rule of thumb, for the most part you get the former during chargen and the latter you gradually accumulate during play. Plenty of exceptions!
Aside from those, there are also dependencies (like in Diablo!), the need for a particular tutor, specific items, sometimes even events, a few are culturally locked (fewer still are racially locked), etc. The prerequisites for skills and skill trees are as varied as there are skills. Some you get automatically based on the concept for your character, many you acquire during play, but they are always “natural” things you engage with anyway while playing the game, and never based on a dedicated “progression currency/point system”.
In fact, that’s more or less the whole point to this elaborate exercise. In my quest for making this mechanic associated, I realised that there’s nothing more associated than having it be pure interaction with the setting via roleplay and mechanics that already worked naturally with that. The only thing that I have to do as the designer is make sure that these prerequisites are seeded into the setting. Which, in a game like Chimborazo that comes with the setting built into it, will happen automatically and becomes purely a matter of making the necessary content for this mechanic.
Upgrading skills
With the most critical part of progression out of the way, I started thinking about how to make skills upgradeable. Now, strictly speaking, that’s not necessary per se. When I thought about the fundamental reason why abilities get upgrades in games, I arrived at the conclusion that they usually do it for the purposes of keeping older skills relevant later into the game. But Chimborazo isn’t interested in linear progression through the game, because it’s an open sandbox environment5. The game doesn’t have planned obsolescence when it comes to skills – there are no “strictly better” ones – but that doesn’t mean your base skills should remain viable in any and all situations. Skills at the top of a skill tree are there for a reason, after all. At the same time, that doesn’t meant they are always applicable where simpler skill will do the job.
For the reasons mentioned earlier – because of the fundamental difference in questions that the game asks the character – and because skills don’t have to scale into the “late game” due to the lack thereof, plus the fact that skills already inherently improve over time because they scale off of the character’s stats (if a stat progression system were to be implemented), it turns out that in Chimborazo, getting better at doing something means getting to do it more reliably. To that end, coupled with my desire to make skill upgrades meaningful and personal to the character, I introduced the following two properties6 for skills:
Established action
Settling on what the upgrade does was very easy, actually, the minute I knew that upgrades mean reliability over more raw power. Using your character’s stats is the most reliable way to do something, so for skills I simply applied the exact same approach: once it’s established within the fiction that you can do something consistently and reliably, it becomes what I’ve unimaginatively dubbed an “established action”. The roll of the dice is removed from the skill unless there are extenuating circumstances that would cause uncertainty7, and even if there are, you automatically get an instance of advantage when you have to roll8.
(Clarification for context: Why is removing rolls from skills considered a good thing?! Well, in this game, dice aren’t a strict positive. The base roll is d6-d6, which means anything from -5 to +5. You are removing the chance for dice to improve the skill, but also the chance they make you fail it. The improvement comes from elsewhere once the roll is removed.)
That’s the effect, but how is a skill upgraded in the first place? The challenge here is to find a method that satisfies the design pillars I mentioned in the beginning:
- Be a completely associated mechanic. It has to make sense that this is the skill you’re upgrading, a.k.a. “to get better at something – do that thing”.
- Represent your mastering the skill as a process.
- Not be too difficult to track your progress in it.
The first one appears to be very self-evident. I can just track skill usage. The problem is that this almost directly contradicts the third philosophy of minimum tracking. Took me a while to reconcile these two, but eventually I was able to realise that I can piggyback off of short term memory without forcing people to write down things. Instead of tracking abilities as they are being used, instead I can make them recall memorable events as long as it fits a short enough time frame. Which is exactly what I did. I decided that a single gameplay session, whether two hours, four, or even six, is short enough that everyone will be able to recall if something notable happened. Extensive playtesting confirmed this hypothesis, and with that, I had a neat little box (of time!) to work with. On top of that, keeping it contained to a single session means there’s also no need to track progress between sessions – in other words, no taking unnecessary notes.
Now, obviously, I can’t make people backtrack and recall every little detail like asking them to pay attention to any and all skills used. Plus, this still leaves out the second philosophy, which is that this process has to represent mastery. So the tricky part here was to re-frame that into something more useful. In this case, my thought process was that I can see if the character has reached mastery by looking at if they’re performing way above average consistently – when they are, I can “solidify” that into officially recognised mastery, and if they “prove” it once, they don’t have to do it from that point on.
To that end, I ended up introducing a new character condition called “with the odds stacked against you”9, which checks if a character is under a negative condition which impacts the skill being used or rolling with disadvantage when they use a skill. When they do so successfully, I consider that to be above average performance. For consistency, I’m going with the tried and true “number of times in a row”. In this case, three. It’s arbitrary, yes, but I think (and playtesting has long since confirmed) that it’s a good balance between being hard to do but not impossible. When all is said and done, I ended up with this final version:
Established actions don’t involve a roll of the dice (the GM can always require one) and succeed automatically if their value is high enough. If a roll of the dice is required, it comes with overwhelming advantage10.
Straight out of the w.i.p. Chimborazo book
In order to upgrade a skill to an established action, you must use it successfully three times in a row with the odds stacked against you, over the course of one game session. Once this condition has been fulfilled, the skill immediately gains the established action status.
Note that “in a row” doesn’t mean “three consecutive actions of your character” in this case. The idea is very much not about making you abuse the action economy or making you feel like you have to spam the same action (skills are actions) over and over again. All it means is that, within one session, from all of your uses of a certain skill, three of them consecutively have to succeed under the aforementioned conditions. Of course, any time a game doesn’t explicitly prevent you from using a skill over and over (usually, quite artificially so), there’s bound to be skill spam in the hands of certain players, and I’m looking into that as well, but at least it’s not an unwanted by-product of the progression system specifically. If it were, I would probably have kept looking for an even better approach.
At this point, readers that paid attention will have recalled that early on I mentioned that “everything is a skill”, including passive abilities, and they noticed that in order to upgrade a skill, you have to “use it successfully” multiple times in a row. How do you use passives multiple times, let alone in a row? Excellent question, dear reader! I think I might have a solution and it involves passives affecting their targets for the first time (yourself included, for things like self-buffs). It’s a work in progress, but sounds doable, even if it’s not the most elegant mechanic in the world.
Signature ability
Frankly, I could’ve left skill upgrades at that and been pretty happy about it. After all, skills scale with stats, so if ever I found a way to have those increase over time too, that’s extra upgrades of all skills that use them, in the long run. But there were a few things that slightly bothered me, such as:
- Simply it being established that you’re not going to fail at something, barring outside influence, didn’t strike me as the ultimate expression of mastery. When it comes to consistency, surely there is a level of mastery that removes any doubt in your abilities, right?
- Couldn’t you become an expert in the whole “field” somehow?
- In terms of making progression intimately tied to the character, is there a way to make these upgrades more personal?
It was very hard to find a satisfying breakpoint for the next tier of progression… and by satisfying I mean one that didn’t feel forced in some way. So with the above questions in mind, I set out to explore what more I could do in the direction that the “established action” tech had already taken me in. At some point during that process, I realised that you’re very likely to end up with a few established actions in the same skill tree, and that pushed me to think in the direction of “completing” skill trees. That felt like a very worthwhile thing that I could be interacting with. There was a slight problem with characters who might opt to not take every single skill in a tree, so I had to be more flexible in terms of what maxing out a tree means (or force them to take every single skill in it before a tree can be completed, ugh) but I had two interim solutions for that problem. The first being tiers, aka you get all skills in a given tier on the skill tree if you meet the prerequisites. The second being looking at having taken a max tier skill on that tree. This is still a work in progress, but the specific way I’m going to let somebody mark a tree as completed isn’t nearly as important as the fact that once they’ve done so, they will have a tree marked as completed. For the time being, I’m relatively happy with the condition for maxing out a skill tree being that you need to have three skills in it upgraded to established actions. It ties the second tier of skill upgrades more intimately to the first.
Anyway, the point was that maxing out a tree is a tangible event that the game can read and that I can use. In a sense, it represents mastery over an entire field, because a skill tree covers a whole field. This way I was hitting the goals outlined above. So, what happens when you max out a skill tree? You get a signature skill!
Signature abilities automatically succeed unless opposed by other signature abilities. In that case, they have overwhelming advantage.
Straight out of the w.i.p. Chimborazo book
In order to upgrade a skill to a signature ability, first it must be already upgraded to an established action and its skill tree must be fully unlocked*. If that’s the case, you can nominate a skill from that tree as your character’s signature ability.
This is how it works for now. The whole nomination thing is a cute idea about how in order for something to be your “signature” action, it has to be recognised as such by your peers, but that has some slight issues associated with it. I don’t have a way around those at the moment, but it’s something I’ll have to actively look into very shortly.
Upgrading stats
For the longest time, I didn’t have a way to upgrade stats. And the game was fine, actually. It’s not so much a mechanical necessity which it can’t function without. However, it was always something I wanted and planned to do eventually. Plus, it makes a lot of sense – due to the nature of what stats represent, it would be a bit weird for them to not change over time (preferably in a positive direction, but the reverse isn’t necessarily impossible or always a bad thing to include). And lastly, players coming in from other games expected stats to change (but really – grow) over time, and as we all know, fighting against human nature is a losing battle. Besides these main points, there are more and subtler reasons to have stat growth as a feature of the game, and I was thrilled to finally find an elegant solution.
The main problem initially was not having something tangible on which to base the stat increases. There are very few boxes for the game to sort characters by, due to its lack of anything concrete within the progression system like levels, experience, etc. In fact, this very fluidity is one of its main strengths. Even outside progression specifically, it’s hard to find suitable rigid platforms from which to jump off into stat increases. There are no classes, races matter barely to not at all outside of the “super special racial properties that make your gameplay unique from that of others”, culture would be a very weird thing to tie to your stat progression, and skills… well… skills are actually the progression system so far11, and you do get new ones all the time (if you want to), so they are a possible tangible jumping off point. Except that skills have the reverse relationship with stats – they depend on stats (skills scale off of stats), rather than stats on them.
But one day it dawned on me that due to how the game is set up, increasing your stats would actually be the ultimate form of progression. Because stats are used on their own and every skill scales with (at least) one, every single point put into a stat gives you a ton of mileage. So, with that re-framing of stats’ position within the progression hierarchy (which now became: new skills -> better skills – > more stats), I started to explore ways to tie stat increases to skills. They have to go after skill upgrades, but how? To than end, I reminded myself that the previous best form of progression was maxing out a skill tree and nominating a skill to become your signature ability. Well, if “maxing out a skill tree” is a distinct trigger that the game recognises, then maybe stat increases can somehow be based on “completed” trees. Actually, the very first idea that came to mind wasn’t too far off from the final implementation. There’s a very small and extremely easy leap in logic one can make from “completing a tree as a requirement to have some way to increase stats” to “completing a tree increases its governing stat”. This has some slight issues that have to do with split scaling and other minor features of the game and power concerns in that its double dipping into tree completion (you get a signature ability and a stat point!), but overall exactly what I was looking for. So it stayed that way for a few months and players were really happy with the implementation.
Around that same time, I was working on a system that I call “scalability”. This is the ability of the game to zoom in and out of the time scale, aka pacing. Skills cover operations at the highest zoom level, but I ran into problems as I tried to scale up toward downtime. At some point I figured out that while a skill is a singular activity in a particular field, at the highest zoom out mode of playing the game, you won’t be engaging with singular activities. So I asked a very brave question. What if you could “use” the whole skill tree? Yes, as an action, just like you would use a skill, except at a very big time frame.
Well, that turned out to be a rather brilliant question to ask12, because exploring the answer solved a bunch of issues simultaneously. This is something I do quite often – I’ll question everything and ask even very dumb questions, then go down the rabbit hole in search of answers. Sometimes I come out the other side covered in dirt and tears, only to find out the proper reasons why it was a dumb question to begin with (I still find it worthwhile because of that discovery). Other times, like here, I come out holding the golden carrot that is the solution to world hunger and cures cancer:
A skill tree is just a thematic grouping of related skills, with the same base requirements and governed by the same stat(s). It’s also the most rigid “box” that Chimborazo has to offer. If a skill tree has a strong enough coherent theme, and I posit that it should, then really it’s an umbrella terms for a swath of related activities. In other words – a discipline. And a discipline is something rather concrete that you can “do”. At the highest time scale, an “activity” represents many, many actions, over a period of time. Sometimes a substantial period. When all of them are somehow related, well, you’re “doing” that discipline. Under that frame of mind, it suddenly started to make a lot of sense how one could “use” an entire skill tree as an action.
First things first, this immediately solved my implementation of scalability at the lowest and highest ends of the spectrum (skills and skill trees, respectively). I still have work to do on the middle areas and exactly how granular I want to make it, but now I have both quantum actions and downtime activities without adding new content and with the addition of a single, tiny rule. Next, I have a great platform to use for stat increases. I decided that a skill tree can always be used for its corresponding downtime activity, regardless if it’s completed or not (in fact, that’s how you’d probably meet further prerequisites for them), it will just be more efficient the more you progress through it (the details of that are pending, for now). However, once completed and you have your signature ability from it, a tree can be used as a one-time special downtime activity in order to increase that tree’s governing stat13. The great thing about this approach is that it’s a feedback loop into the rest of the progression system – it’s a built-in incentive to go into new skill trees and diversify and an incentive to go up the tree, because in the end it will allow you to upgrade its stat
This turned out to be a rather brilliant way to do things, because it worked out superbly with everything I wanted to do. And on top of solving scalability for the game, it also solved the problem of upgrading stats. Previously, maxing out a skill tree allowed you to get a signature skill in that tree. But I wasn’t doing anything with the maxed out tree itself. While searching for downtime activities to do with the skill trees, I decided that this would be a great way to use them to increase stats.
In order to increase a stat by one, you can perform a special downtime action with a one-time usage of a fully unlocked skill tree that scales with that stat.
Straight out of the w.i.p. Chimborazo book
When a skill tree is used that way it can no longer be used for stat increases by the same character.
And with that, this epic tale in trials and tribulations of finding the perfect fluent progression mechanics is concluded.
Notations:
1 – Few things in games annoy me as much as dissociated progression mechanics. Don’t you just love it when you spend a whole session obliterating monsters by casting Fireball on repeat, then you get enough XP to level up, and when you do, you can choose to upgrade your STR stat and get access to Frostball and a feat that makes you a better swimmer for… uh… reasons? Well, I don’t. I find all of this repulsive as a gameplay experience, because it’s completely and utterly dissociated as a mechanic from the fantasy of the roleplay. It breaks immersion via how utterly nonsensical it is.
2 – Usually by becoming stronger in one aspect or another, yes, but since in Chimborazo stats are descriptors for the character’s very being, advancement in that respect just feels innate and personal. It’s very satisfying as a whole, even if that feeling were abstracted from the fact that it’s a powerful effect mechanically. I’ve also tried to evoke that experience with the way skills advance, too, making them tied to the character in an intimate way.
3 – I’ve been planning for some time now to develop better language when it comes to these things. As much as it gets the point across, I’m not a big fan of describing things by what they aren’t. In the absolute best case, you can do that when there’s only two possible states in which the thing can exist. A statement can be true or untrue, and that’s it. However, when it comes to more complex classifications, “undescriptions” become increasingly useless. The only reason it kind of works here is because of the elephant in the room and how other games set themselves apart from it.
4 – Hey look, a box!
5 – Yes a character “grows” over time, and in that sense they are perpetually getting “stronger” in an abstract sense, but this is expressed more so through the ability to solve more varied problems. The world around the character doesn’t scale with them, because it doesn’t care in the slightest about them.
6 – They are basically “tiers of upgrades” for the skill, and sometimes I refer to them that way, but mechanically they are special tags that some of your skills get labelled with.
7 – In essence, this makes the skill behave exactly like a stat check does.
(OK, yes, this article assumes some knowledge of how Chimborazo works – for which there currently aren’t any articles, but there will be in the future – but lack of this knowledge doesn’t really impact anything when it comes to getting your time’s worth out of this article.)
8 – This, in turn, makes it behave exactly like a stat check when your primary stat is involved. See the pattern yet?
9 – The dire need for a better name is evident, thank you very much.
10 – Overwhelming (dis)advantage is simply one that’s always true, regardless of how many instances of advantage or disadvantage are influencing the skill. It cancels out all others.
11 – That is to say, in terms of intrinsic character progression. Technically, acquiring new items is also a type of progression. And a relevant one at that, too, but not reliable and always available to characters the way skills are. Other forms of progression include narrative progression, meta progression, etc. Let’s hope I write an article on progression types soon.
12 – I am widely known first and foremost for my incredible humility.
13 – This ties in to the practical observation that doing something as exercise can only help you improve up ti a certain point. If you wanted to go further, you’d need to do other things. Like trying to get stronger solely by running. That won’t work. Or like trying to improve your mental abilities solely by doing one type of sudoku but not playing any chess. Improvement comes from diversifying your skillset.
