Breaking down abstract Classes (occupations)

TL;DR at the end.

There may have been some threads somewhat related, but they are quite old. So rather than being an evil necromancer, I’ll start a new topic.

Background:

One of the biggest draw to me for games like Stonehearth, is the emergent game elements rather than abstracted results.
The current Class sytem, however, seems like a abstracted “set meal” forced onto the hearthlings. In particular, these don’t feel … “right”:

  • Class has its experience/level which seems to be an aggregation of the levels of “skills” (or abilities) associated in a class. This is especially strange when different classes has an ability that is almost the same.

  • Class skills becoming usable when 'deactivated".

  • Difference classes may have methods that achieves a similar goal, but a hearthling that was trained in both just uses the active classes’ default method and not the BETTER method.

Model:
Note: this was done in less than 15 min, so it may not be complete.

The goal of this, is to attempt to provide a more flexible model to the relations between a Hearthling’s skills, capabilities/attributes, a “class”'s duties and preferred methods/ablilities as well as other things which are not obvious (e.g. tending to needs like hunger)

Fundamental: when listing down the concepts, I group the concepts into 3 groups which reflects the conceptual constraints on them:

  • reality : these are concepts which models real stuff. There isn’t really a lot of choice at higher levels and is fixed at engine/system/simulation level.

  • strategy : these are methods (including optimizations) which is built on “reality” layer. Though there is some flexibility, it relies on the use of “reality”, which retricts the range of possibliities. i.e. there are possible choices compared to reality, but assuming optimization, the range of possibilities is limited.

  • policy : these are totally customized, and can take any form.

Example of above 3 group: a hearthling archer considering attacking a group of enemies.
In this example, the following break down points are:

  • policy

    • occupation: archer
    • has duty: attack enemies
    • prefers methods:
      • range attack (with bow and arrow)
      • keep distance
  • strategy

    • goal: attack the enemies
    • methods:
      • range attack (with bow and arrow), or
      • melee attack (with fists or some other equipment)
  • reality

    • performs range attack (with bow and arrow):
      • equipment: bow and arrow
      • hearthling has visual sense and is good enough to see the enemies
      • hearthling has arms and hands of enough strength/dexterity/etc (or equivalent) to operate the bow and arrow
      • hearthling has enough knowledge (skill and level) to make the attempt
    • performs melee attack (with fists)
      • hearthling has arms and hands of enough strength/dexterity/etc (or equivalent) to punch
      • hearthling has enough knowledge (skill and level) to make the attempt

In the 3 groups, reality has no room for compromise. Strategy has some options, but is limited by reality, and policy has the most flexibility, in what occupations having what duties and which methods preferred (though methods themselves are limited by strategy)

A simple (and may not be too correct) diagram illustrates the relations.

Thoughts:

  • jobs can be independent defined by one party (though some are “limited” to certain occupations). These just represent “what needs to be done” and can be generated by various sources.
  • classes/occupations defines a preference (including the concept of permitting/not permitting) for jobs. In fact, we can even have dynmaically customized class/occupation for a single Hearthling by manually setting preferences for all the possible jobs. (setting to to a “standard” occupation is just a shortcut to manually setting all the job preferences according to an occupation template).
  • Multi-occupation is possible by just mixing the job prefernces in some way (more than one way possible: e.g. conjunction, disjunction, addition, multiplication etc)
  • jobs have a goal, goals are achieved by methods (though a single goal may be achievable by more than one method)
  • a Hearthling can choose any method to achieve a goal as long as the method requirements are met, but this choice can be influenced (weighted) by preferences stated by the occupation, personal attributes (interests, characteristics), or others (e.g. racial/community level preference)
    • a Hearthling tending to his own needs (like hunger etc) are not part of the class/occupation, but a “sibling” model which is in “reality” (e.g. hunger). Implementation-wise however, this can be a “job” of a “class” called “living things” which is mandatory.
    • this model just describes how things may work behind the scene, and may not need to be all exposed (e.g. we could still use current UI and concepts of fixed classes). But it would also make it ready to be exposed incrementally.

Summary/TL;DR?:

  • Current Class system is abstract. It is sort of an “anti-idea” to the way StoneHearth tries to be: emergent behavior from simulating the factors beneath. It also does not rationalize concepts such as skills.
  • What a Hearthling can do does not imply that he should be doing it and vice versa^inverse.
  • By breaking down Class, it ended up as just a (player) “policy” which points out the possibility of individually customizable class for each Hearthling. (templated classes can be used for convenience)
  • allows parts like class, jobs, actions, methods to all done by different parties and combined flexibly.
  • hmm. in the end took an hour to write this how thing (including 15 min for the image). Again, this may not be complete and is meant more as discussion fodder.

thanks for reading if you reached this point :wink:

1 Like