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