Change professions and workshop reuse

When my carpenter dies, I can’t reuse that workshop anymore. If I promote (or get a new) carpenter, they don’t inherit the old workshop…ugh.

Also if I’m low on regular workers (and the population doesn’t increase very fast either) it would help to be able to re-assign that rng farmer I got into a trapper (that just bit the dust).


Well I can certainly see this as being an issue. As for:

It’s something that has popped up a few times now, and I’m not sure where Team R stand on the issue (@sdee @tom and everyone else). I say this because the idea behind class progression so far is that the team want it to be a thought out meaningful action - in that your decision to upgrade to a carpenter or a footman etc. is a solid choice that directly impacts the way your settlement plays out.

Not being able to change classes randomly means that the game wants you to think about your wants and needs - “do I upgrade to 3 footman and become a force capable of defending my settlement and taking the offensive” or “do I upgrade to 2 farmers and a footman to bolster my settlement growth but potentially leave myself a little exposed”.

In other games similar to this you can change classes at any time I believe to meet the demands of your settlement on the fly, and both systems certainly have their merits. The one thing about the system in Stonehearth is that if not handled properly then I can see there being optimum progression paths that everyone takes essentially rendering the choice and the system itself practically useless - though that is just conjecture on my part at the moment.

All in all, this turned out to be a longer post than I intended, and it would be interesting to hear where Team R stand on class progression at this moment in time.


One thing to remember with Gnomoria, Dwarf Fortress, etc is that you can create custom jobs, but Stonehearth doesn’t allow this due to the workshop/talisman system. In other games, units also have a skill at a job that determines how good they are at it, whereas Stonehearth doesn’t have that (okay, your trapper can level up, but your carpenter still can’t make “Awesomesauce, the Bed of Kings” etc :stuck_out_tongue: ).

Personally, I think I prefer the DF/Gnomoria model as it’s more flexible (esp as Gnomoria lets you import/export custom jobs to save time), but at least initially it does require more setup time.

Very likely. Well… certainly games like DF have similar recommended paths initially (ie “always bring a miner” or “make sure you have some spare pickaxes” etc), but beyond that I think they allow for more creativity.

Ditto :slight_smile: .

Okay, some thoughts on doing a custom job system in Stonehearth, for @sdee, @Tom et al…

  1. In place of the carpenter’s saw at the start, you have a carpenter’s workbench you can place.
  2. When you make someone into a carpenter, they go over to a free workbench and pick up the saw & do the cute “class chosen” animation.
  3. All new citizens are Workers when they join, at least for now.
  4. The professions UI will need to be completely redone - see below…

4a. At the top, a drop-down menu for jobs, plus a button to add/remove a job. Cannot remove the default “Worker” job.
4b. Pick a job on the drop-down menu, and the bulk of the UI screen becomes a list of tick boxes of skills etc to be used in this job (eg Carpenter: “yes to carpentry, no to woodcutting, yes to hauling, yes to building, no to farming…”).
4c. Import & Export functions for custom job files.
4d. By default you start with a list of jobs equal to the current jobs (Carpenter, Trapper, Footman, Farmer, Weaver, etc).
4e. Some skills in the list of tick boxes will have skill requirements, eg “Requires 200 Trapping skill” to tame wild beasts or whatever. This allows you to differentiate your trappers from your animal tamers, etc.
4f. Pick a costume for your class (eg “my trapper looks like a footman” situations are possible).
4g. Pick a uniform for your class (eg “all footmen must use iron swords, helmets & breastplates, if I have any”).



Sounds to me a lot like the Dwarf Fortress system, which I personally think is kind of cumbersome… My original impression of this game, when I first saw it, was that it would be slightly less heavy than DF if the players wanted it to be. Maybe the final result could be a mix of the two? Where you can detail very specific behaviors, or you can just use presets if you’re still just learning the game. Or maybe it could end up like farming, where you could give them specific behaviors, but you’d have to do a bit more work for it.

Exactly - I think having pre-set occupations is definitely a good idea - I mean, a carpenter is a carpenter is a carpenter, and the only real change you’re likely to make there is whether they haul items and chop trees or not :stuck_out_tongue: . However, there’s plenty of other things where you might want a custom job (swordsman vs axeman vs hammerer, etc), so having that functionality in there would be good, especially in a sandbox game.

1 Like

Definitely, I think I prefer this hard system over DF just because it feels more meaningful, or that, each uni has more purpose in some way?

Maybe its just me :slight_smile:

1 Like

Could implement a class/sub-class system. So you’re primary job == carpenter, but you can assign your sub-class to a worker or builder or farmer. I’ve not played DF, so I can’t speak to that system. I do agree that I like the idea that you plan out your people’s jobs and that randomly flipping back and forth wouldn’t be that good (or at least not without a cost).


Being able to give the carpenter’s saw to a new settler after the first carpenter dies is a no-brainer, but I’m ok with not swapping jobs on the fly.

When I play DF, I end up making anyone who’s worth their salt a single-task worker so they don’t get distracted doing something else. Everyone who’s not particularly good at anything ends up being mass labor for hauling, farming, construction, etc. Stonehearth more or less has the system I like in place by default, no micromanagement required.

Tweaking labor settings could be useful, however, in order to restrict/allow crafters to participate in general labor like house-building when they’re supposed to be cranking out furniture.

The cost in the DF model is that each job has its own experience / skill points / etc. So if your carpenter suddenly takes up weaving, he won’t be a good weaver until he’s been at it for quite some time.

Now, this is something we’re missing though in Stonehearth, should we want to use the DF model: item quality. For example, ATM in Stonehearth, all comfy beds are equally good. But in Dwarf Fortress, Gnomoria etc, a legendary carpenter will make the equivalent of “Comfy Bed +5 Snugness” each time, whereas a newbie carpenter will just make a regular Comfy Bed.

Without the above, then I agree that the DF model doesn’t make much sense. However, given that Radiant are talking about RPG-y mechanics in Stonehearth, I think it should fit in pretty well.

Final point: the DF system makes it easier to recover from disasters, because you can reassign everybody as necessary, albeit at a big cost in terms of productivity / quality.


I like the idea of item quality and would expand that to everything…you know that bed you’re sleeping will start to break down and need to be replaced. Of course part of me believes that the carpenter/bed owner would replace the bed on their own, not requiring me to take care of it. Could be an interesting way to “upgrade” items in a home. You could tag a bed to be replaced with a comfier one later.

Though…I would need to grow more trees to keep up with lumber demands too.

Thanks for all the thoughts! We’re working on this right now so they’re super useful.

I could make some comments as to where we stand right now but the feature is still a WIP, and all details will likely change when it’s complete, and we see how it actually plays. Making sure the game is enjoyable is much more important to us than any particular implementation.

That said, I can talk a bit more about base principles, and let you draw your own extrapolations from there:

Before we started this exercise, we looked at a lot of different games, and tried to analyze why their class/skill system was structured the way it was, and what impact/flavor that imparted to the experience of playing the game. We concluded that the goal of most class systems is to create a cohesive and interesting entity out of a set of skills. That entity might be a person, or it might be a town or army.

If skills were highly customizable within a single person, the player’s attention focuses on the individuals. If the skills were fixed for a given person, but you could collect multiple people, the player’s attention instead focuses on balancing the group as a whole. The easiest games to grasp (in our opinion) were ones in which the degree of skill customization matched the size of the population (the scope, if you will) that the player was expected to control.

Here are some extreme examples: In Skyrim, you control just one person in a giant open world. This works really well with the game’s fine-grained skill-oriented leveling system, since you can tune and tweak your lone protagonist to your heart’s content. If you make a very unique thief/mage, that fits the fact that the game is constantly inviting you to explore unique parts of it (this dungeon, that crafting tree) and thus your protagonist.

In FF Tactics, you control a whole army. Though would be theoretically possible to manage Skyrim-levels of skills for each person you recruit, the game wants you to think about the group as a whole, and makes this easier for you by consolidating skills into class-sets, and making each class unique. The narrative of the game then becomes about how person X helped person Y, instead of being about person X’s personal development arc.

In D&D, WOW, and other systems where you control a single character with a set of class skills in a game designed to be played as a party, social dynamics suddenly become a tremendous focus of the game. If you’re the evil assassin, how do you know the good cleric will heal you when you need it? In these cases, the granularity of the distribution of skills makes social interactions as much a part of the game as any of the in-game mechanics.

Conceptually, Stonehearth is a lot more like FFT than Skyrim, and we’re not yet thinking about town-level specializations for multiplayer (though that’s undoubtedly coming, eventually). Right now, you the player control a town, and though we want each person to be endearing, there will probably (eventually) be too many people to cultivate at a fine grain. Each person, thus, gets a class, and each class gets a unique profile (both skills and appearance) and you control most classes as a group, rather than at the individual level.

Your town as a whole (and the trajectory of your game) should be identified by the balance of classes within it as opposed to the specifics granted to each person.

But what about customization? Just as Skyrim implements the perk/level system to prevent people from building characters with 1 level of every skill, and just as FFT allows you to multi-class and specialize your characters so that some individuals stand out from the mob, Stonehearth’s class system too should allow for making unique people with unique stories if you the player so desire it. To that end:

  • Yes, you should be able to change classes, from carpenter to farmer to trapper etc
  • Changing classes should in general be expensive (see note), and not done lightly. For example, perhaps it’s hard for a high-level trapper to pick up basic farming skills
  • Some classes may be cheaper to change into than others (your army of footsoldiers may all reasonably work construction when there’s not a war on)
  • If your high level fighter wants to retire to be a carpenter, he should still be able to pick up his sword and defend the town when Cthulu attacks
  • Re-using workshops makes sense, but because of efficiency. It shouldn’t add any micro to the game. You know how Tom removed the promote button from the talismans, so you can’t pick, anymore, which talisman goes to which person? Imagine that you are not party to your peoples’ inheritance dramas. :slight_smile:

Basically, expect that in Stonehearth, when people do stand out to become more than just a class (because we love stories about heroes and villains) they will be the exception, rather than the rule.

(note) Expensive? Why expensive? We looked at the expense of multi-classing in different systems too, and concluded (again) that the expense of diversifying skills increases according to the importance of the group, as opposed to the individual, in the game. Tiny example: Final Fantasy X has a highly specialized party of 7. Each person is strongly archetyped: black mage, white mage, blue mage, tank, thief, status-effect-inflicter, time-mage. You’re only allowed to multi-class at the very end of the game, and it is super expensive to do so: hours and hours of effort. FFX-2 has a reduced cast of 3, but it’s a sequel so the designers still needed to fit in everyone’s favorite skill combos. Result? Multi-classing is cheap and easy, and can be done between rounds of combat.

Stonhearth has a large cast, so allowing easy swapping between classes leads to lots and lots of decisions per person, and opens the door to micro. Ergo->class switching is expensive, though again, we’ll play it and tweak it till it feels rewarding, not punishing.

Last note: Balancing the game across all possible class combinations is hard, and things like random bonus drops, and tiny variations within classes make it harder. Like a good painting or sculpture, expect the classes and people to be designed in general, broad, deterministic strokes first, with randomizing little elements and flourishes to be added at the end, after the basics are baked.


[quote=“sdee, post:11, topic:7855”]Before we started this exercise, we looked at a lot of different games, and tried to analyze why their class/skill system was structured the way it was, and what impact/flavor that imparted to the experience of playing the game. We concluded that the goal of most class systems is to create a cohesive and interesting entity out of a set of skills. That entity might be a person, or it might be a town or army.

If skills were highly customizable within a single person, the player’s attention focuses on the individuals. If the skills were fixed for a given person, but you could collect multiple people, the player’s attention instead focuses on balancing the group as a whole. The easiest games to grasp (in our opinion) were ones in which the degree of skill customization matched the size of the population (the scope, if you will) that the player was expected to control.[/quote]
Hmm. I get what you’re saying here… I’m just not sure I agree with your conclusions.

  1. The way I see it, Stonehearth is neither a town management sim nor a RPG - it’s a bit of both. You have to manage your town, sure, but the individuals within it matter (or should matter) to you. When Bob dies, that should mean something to you. But his death matters less when you can fairly easily replace him.

  2. I think you’re wrong anyway :smiley: . Most of the Dwarf Fortress LPs etc that I read seem to have a good mix of individual stuff and town stuff: too many / too few people farming, and the town starves. But at the same time, the flexibility of DF’s skill system means you can more easily get the fun individual tales of crazy derring-do, overqualified everymen (everydwarves?), and so on. Remember, there’s no need for a DF skills system to be complex for first-time users: premade / default skill sets are an ideal way to ease new or inexperienced players into the waters of the skill system.



I think you want to have enough control over each citizen to make them feel ownership. I get this when using the “stamp” to approve a class change…I don’t get that when choosing a class in the tree (as an example).

I do also agree with wanting to control focus on a single citizen or on a group or on a “town”. But on the sim side, I should be control of which level I’m focusing on. Why could I not be able to do all of them (if it takes me 3 hours, so be it)?

As an aside Archeage classes work to harmonize on a single “class type” which is part of 3 different trees combined. Taking from that, you could possibly do the class/sub-class on a citizen and then if you had say 4+ citizen each of that class/sub-class type they would create a “hall” or some other specialized “options” or “town-level” stuff, etc.



No that is some really nice input and some great ideas and perspectives :slight_smile:
Oh also welcome aboard if nobody have said it already.

1 Like

This is what I have been trying to say, by the phrase a carpenter needs to be a carpenter (a worker = a worker), because if my town is based on worker+ and worker ++ then I have to micro every worker interaction.

Below is how I would see the worker tree:

1 Like

Another random thought…should the worker tree show many of each are already assigned in your “town”?


aye, this would be helpful… and i think it was originally suggested when the blog first revealed this profession tree…

edit: in light of today’s desktop tuesday, it seemed fitting to push this back to the top, and see if it sparks some additional conversations… really interested in seeing how the change professions process will get ironed out… :+1:


I am working on the latest steam alpha version.
This is still an issue.