Another look at worker advancement

As Strategic Primer, my strategy game, has developed—from its beginnings as the apparatus for my eighth grade science fair project, through the in some ways vastly different conceptual iterations I took it through over the next decade, but especially as the current campaign has put my ideas to the test—I’ve had various ideas about how to model and manage the improvement or advancement of workers and units. Because a couple of the players in my current campaign have asked about worker advancement recently, today’s post is a look back over what I’ve said about it over the last few years, and an introduction of some new ideas that I think will work.

Not long after the campaign really got underway, in May 2010, I introduced the first mechanic for worker advancement in this post. It describes the concepts that are still in use right now: each worker is modeled like a character in an RPG, with Jobs (equivalent to classes) and skills. And it provides the mechanism for skill advancement:

Every time a worker trains in or uses a skill, the character’s chance of gaining a level in that skill increases slightly. (This counts no more than once per hour, but each hour of lengthy use or training counts separately.) I’ll determine at the end of each turn which workers, if any, gained levels in skills. The chance of leveling resets to zero when the level is increased (or, more precisely, gets reduced by 100%, then raised to zero if negative-continuing training even if it puts the character beyond a certainty of leveling won’t be penalized).

I then described a similar mechanism for gaining Job (and thus character) levels randomly as skill levels increased, but I think my new idea addresses that problem better, so see below.

A year and a half ago, in this post I considered moving away from Jobs as anything beyond a description of what the worker is currently working as or training in. My new idea abandons that tangent, but does incorporate the ideas of “feats” and “traits” that I mused about in that post.

Lastly, little more than a year ago I revisited the topic after noticing how players’ populations had grown. I recommended that players concern themselves with units rather than individual workers. I’ll quote most of that post here:

A “worker” (a character) has essential statistics (as in many RPGs), including a number representing health. He or she has ranks in a number of skills, representing training or experience, and gains more by using those skills or by training in others. Each worker gains “character levels” with either the passage of time in the player’s service, or the accumulation of a certain number of skill levels (I haven’t yet decided which), or with sufficient combat experience; each “character level” brings improvements, which will at some (but not all) levels include increases to core “statistics”, and always improved “health”.

For the most part “Jobs” (which were intended to function the way “classes” do in most RPGs) will become a less granular way of describing what a worker is doing than Skills. (For example, “farming” rather than “planting” or “reaping”.) However, a few exceptions will let characters exchange restrictions on equipment and conduct for substantial benefits. (For example, candidates for knighthood.)

But for the most part, in future players shouldn’t have to be concerned with this sort of details. Populations are such that units, described in terms of their manpower, equipment, and occasionally training or experience in general terms, should become the player’s concern more than the individuals from which those units are constituted. (And future campaigns will start closer to this stage of population than where we began the current campaign.)

And I hope to have support for all this in the map viewer and other assistive programs Real Soon Now …

(There is some support for such “unit details” now in the map viewer, and there is a program that’s intended for running each turn’s worker skill advancement but is also useful for players to see that progress.)

But here’s what I’m now thinking.

I’ll begin to make a distinction between character level and Job level. The former will be the main thing used for determining improvements “statistics” and “health,” and can be slowly advanced by active service if neither combat experience nor skill-based advancement are improving a worker. A worker will always have at least as many character levels as Job levels.

Levels in a Job represent significant training or experience, and qualification. A worker with a few levels in a Job is qualified to lead (at least by example), and maybe even to teach, some lower-level workers. In Jobs that might be associated with guilds, low-level workers might be called “apprentices,” mid-level workers “journeymen,” and high-level workers “masters.” It’s important to remember that the one level each initial worker started with does not make him or her a master, and neither does even a fortnight-slash-year’s experience!

(For reference, a “level” in a skill is a notable but in the long run not necessarily all that significant increase: for example, being able to get within the rings on a target five or ten yards further away when practicing with a bow.)

Instead of a random process like that for gaining a level in a skill, I plan to produce a list of Jobs and the prerequisites for gaining each level in each Job. In most cases this will be minimum levels in certain skills, or in a certain number of a certain subset of skills, but a significant fraction of Jobs will have entrance prerequisites. Th table will also tell me the benefits of advancing to each level (probably largely skills that can’t be learned merely from a demonstration, lecture, or book and then practicing, but require a crystallization of insight).

I also intend to create a list of traits, representing innate characteristics, and of feats (which need a better name), representing skills that can’t be improved further in the same way that those I represent as Skills can. Some traits may be required to train or practice in, or even research some Jobs, so you’ll want to pay close attention to those. Each newcomer to a fortress will have a small number of traits, maybe a feat or two, and a small or large number of Skill levels (chosen from a list weighted to make more common Skills come up more often), which may be sufficient qualification to give them a few Job (and thus “character”) levels.

Once I have these tables and lists, I’ll go through all existing workers, bringing any that don’t have the necessary prerequisites for the Job levels I’ve said they have “up to spec” and also looking for any that are qualified to gain new Job levels, and give current workers traits that fit where the players have placed them.

Workers that come to players from allied villages should have traits and skills influenced by that background; once I have this model in place it’ll behoove players to invest in their villages.

Any thoughts about these ideas or the relevant issues?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s