Category: Fief

I have some sad news today for Fief fans. I’ve decided to officially call an end to the project.

I’ve been pouring my spare time into this project for the better part of eight years. In that time, I’ve learned a great deal about programming and game design. Combined with the scientific programming from my day-job, I feel my skills as a developer are at a peak. Unfortunately, no amount of skill can stymie the bleeding ulcer that Fief had become.

I have had a great time working on the game. My passion for the project ebbed and flowed, but predominately was positive. This past year, however, has wrecked havoc with that passion. The codebase was reaching maturity to the point where I decided it was important to improve the visuals of the game aiming for eventual release on Steam Greenlight. So I started looking into artists to help with the visual components of the game. This decision however also added administrative duties to my already limited time for programming. Thus my programming work became quite a bit slower as I spent way more time coordinating with artists on the needs for the project. I had to train them on the image layouts and parameters required by the resources. The turn-over rate of artists was ridiculous! Each new artist would proclaim excitement for the project and throw out ideas. I wanted to give them a lot of say in the visual design, so I sincerely listened and supported the ideas I thought were tenable. However, when it came to actually working on project materials, only one amateur artist, Dino, continued to produce output throughout the time period. The others simply stopped working and/or responding to my inquiries. So I had to find new artists to train on the project, and the cycle repeated.  It repeated at least three times over the year.

The frustration that came with all this came to a crushing point. After the last batch of artists fizzled out, I took a break from the project. I got really busy with work from my day-job and let Fief gather some dust in the corner. I tried to return to the project numerous times, but I just don’t have the passion for it anymore. The eight-year flame may have finally gone out. The project was always too big for one person, and perhaps I thought with enough passion and devotion I would be able to put it together. Without that passion guiding my fingers, I certainly cannot.

Thus I will say good-bye to Fief. I don’t know if I’ll see it again, or if the project will be revived at some point in the future. I’m just grateful for all the people that kept encouraging me along the way. I really appreciate your support!

I cannot leave my hands idle, however. I have begun a new project using a lot of the best features from the Fief codebase. Really its a revivification of an old project, the same project I was working on before Fief took over my life years ago. It is a procedurally-generated dungeon-crawling RPG titled Endless Worlds. My passion for this new project is strong and I am determined not to make the same mistakes I did with Fief.  I intend to handle all the graphics and visuals myself and avoid dealing with flaky artists.  It may not look at good, but at least it will not be susceptible to the same pitfalls.  I’ll post more information in the future as the project planning comes together

Thanks again for all your support over the years and I hope you follow along as I embark on this new project.

Time has been flying by and we’ve been working hard on the game. Most of the changes these past weeks have been aimed at streamlining the underlying structure from my original proof-of-concept designs to more robust long-term software structures. The modular design system is in place, resulting in an easily extensible framework for adding new content and modifying existing content. Overall, I’m quite excited to see how far we’ve come and where we are headed.

I started a new day-job last month and have been trying to work around my new schedule. Meanwhile, we are still looking for an artist to join our team, so if you, or anyone you know, enjoys doing graphical art in their spare time, send us an email: arboreantears@gmail.com

In music new, Greg informs me he is working on some wonderful combat music and I can’t wait to see what he comes up with.

So how close are we to finishing this UI update?  Well, if you compare the current screenshot to the mock-up we presented when we started the UI project, we see that we are almost at completion.

Mock-up of the new UI for the main game screen.

Screenshot with most of the new UI elements.

I have a number of UI windows on my list before I will call this project complete.  Some of them minor (e.g. pick-up item menu, skill tracker) and others a bit more extensive (construction interface, in-game help browser). Then we can return to adding new gameplay elements. While it may seem that this update was all about the UI, there were a lot of underlying system changes that went in behind the scenes.  The UI changes are a lot easier to show than code changes, so here is our status on the major changes:

FWT.  The Flexible Windowing Toolkit is a wonderful new tool for rapidly developing new UIs using the libGDX application framework.  It is a multi-threaded user-interface framework that combines the best elements of Swing and Android design.  Most design elements can be written in XML with seamless integration with the Java behavior.  The FWT Window Manager integrates directly with libGDX for smooth rendering while maintaining high responsiveness.  I’m very happy with the way this system turned out.  I can now easily create complex UIs quickly and reliably.  This project is relatively complete, although I may add new features as I require them down the line.

Modular Systems.  If you saw the last post, you are aware of the extensive system redesign that was underway.  That modular system is now working as expected for construction modules and item features.  Additionally, the new skill system is in place, allowing anyone to add new skills to the game.  Additionally, the new construction system will add deep complexity to large-scale building projects with each specialty builder (carpenter, mason, etc.) focusing on the portion of a construction that pertains to their skill and resources.

UIs.  So where are we with all the UIs?  Here’s the progress report:

There have been lots of changes in the world of Fief development.  First of all, we are eagerly looking for an artist to join the team.  Check out this POSTING for more information.  In relation to this, JD will no longer be working with us.  Greg, on the other hand, has finished the title music and is composing some new pieces.  I’m looking forward to see what he comes up with. In the world of programming, I’ve been working on modularizing all the things.

Modular Constructions

Over the past few weeks, I have re-written much my of old code with new intentional designs.  The work started with constructions.  I was working on some new crafting mechanics when I became quite fed-up with my old construction code.  It worked, but it was bloated to the point of being unreadable and generally painful to work with.  So I worked on modularizing constructions and cleaning the code into something that was more extensible and easy to interface with.  I first eliminated my poor object-extension hierarchy of each construction type inheriting from another, with a new generalized construction that can accept modules.  Each module then specifies components that the construction is capable of performing.  With this method, I should never have to change the underlying Construction class to add new features.  I just have to create a new module and add it to the appropriate constructions.  This system allows great flexibility and it really cleaned up any code dealing with constructions.

Here’s some of the new construction modules:

Construction Phases

In addition, I changed the way constructions are built.  Now construction phases are defined which have their own average time to build and required components.  This also allows each phase of construction to specify the tools required and the skill experience gained for that portion.  This allows for each construction to be built in phases by crafters more suited to each portion.

This overhaul required changing all the XML code, both the XML raw files for specifying constructions as well as the save-game XML data. Due to this, I ended up writing brand new XML readers/writers to handle the new formats. Just another part of the great code overhaul.  Here’s an example of one of the new constructions XML code:

 <construct
        id = "native.construct.fire_pit"
        name = "Fire Pit"
        desc = "A fire pit dug into the soil."
        image = "native_construct_fire_pit"
        material = "core.material.soil"
        type = "man"
        >
        <phase
       		time = "150"
        	skill = "core.skill.survival"
        	components = ""
        	/>
        <module
            type = "crafting"
            slots = "2"
            >
        	<mode name="core.skill.generics.fire" mod="1.0"  />
        	<mode name="core.skill.generics.heating" mod="0.8"  />
        	<mode name="core.skill.cooking.roasting" mod="0.8"  />
        	<mode name="core.skill.cooking.stewing" mod="0.8"  />
        	<mode name="core.skill.baking.baking_bread" mod="0.5"  />
        </module>
        <module
            type = "fuelburning"
       	    maxtemp = "1200.0"
            fuels = "" 
            lradius = "5"
            loscillate = "true"
            lcolor = "1|0.6923|0.5|1"
         />
    </construct>

As you can see from the code above, after the basic data, you can define the new construction phases and individual modules.  Also you can see the new String IDs for skills.

Moddable Skills

A new feature is the use of soft-coded XML skills.  Skill definitions were originally hard-coded into the game.  Now you can create and customize your own skill types that will affect the crafting mechanics.  Skill modes and actions that interact with the environment will still have to be hard-coded, but customized skills will be able to be specified for weapon proficiencies and crafting requirements.

Here’s an example of the new skill definitions in the XML:

<!--  SURVIVAL -->
    <skill
        id = "core.skill.survival"
        name = "Survival"
        desc = "Skill with basic survival crafts and starting fires."
        prof = "Ranger"
        cat = "gather"
    	image = "survival"
    >
   	<mode 
    	    id = "startfire"
    	    name = "Starting Fire"
    	    desc = "Starting a fire with the available materials."
    	    image = ""
    	/>
    	<mode 
    	    id = "knapping"
    	    name = "Stone Knapping"
            desc = "Knapping stones to form shapes and edges."
    	    image = ""
    	/>
    	<mode 
    	    id = "tying"
    	    name = "Knot Tying"
    	    desc = "Tying knots with fibers."
    	    image = ""
    	/>
    	<mode 
    	    id = "gather_branch"
    	    name = "Gathering Branch"
    	    desc = "Cutting branches from trees."
    	    image = ""
    	/>
    	<mode 
    	    id = "gather_stone"
    	    name = "Gathering Stone"
    	    desc = "Gathering stones from the ground."
    	    image = ""
    	/>
    	<mode 
    	    id = "gather_mud"
    	    name = "Gathering Mud"
    	    desc = "Gathering mud from the ground."
    	    image = ""
    	/>
    </skill>

Modular Items

After I saw how great the new modular constructions were working, I decided to apply the same design pattern to game items.  Now I have the GameObject class generalized just like the base Construction class with a number of modules, called features.  Just like constructions, you can add as many features as you like to an object (although not two of the same type).

Since I expected items to be far more numerous than constructions (which are limited by the number of game tiles), I still use some of the old template system to limit the amount of data stored for each individual item.  Therefore I have item feature templates that define data for all instances of a particular object.  This data is declared in the item XML definitions for each feature.  When a new instance of that object is created, the templates are converted to features which are added to the object.  The features still link to the original template data for reference.  This allowed me to keep the best component of my old system, that is the maintaining of only a single copy of object prototype data.

Here’s some of the item features that are working so far:

Here’s some of the special item features that are created in-game and cannot be defined in object definitions:

Here’s an example of an item with both a weapon and tool feature:

<item
        id = "native.item.primitive_axe"
        name = "Primitive Axe"
        desc = "A simple stone all-purpose hand axe."
        image = "native_weapon_primitive_axe"
        weight = "4"
        volume = "120"
        material = "core.material.rock"
        >
    	<features>
    	    <melee skill="core.skill.axes" dmg ="S|B" />
    	    <tool>
    	        <mode name="core.skill.generics.chopping" mod="0.8"/>
    	        <mode name="core.skill.generics.slashing" mod="0.5"/>
    	        <mode name="core.skill.forestry.choptree" mod="0.8"/>
    	        <mode name="core.skill.forestry.sawlogs" mod="0.8"/>
    	        <mode name="core.skill.forestry.chopblocks" mod="0.8"/>
    	        <mode name="core.skill.forestry.chopfirewood" mod="0.8"/>
    	    </tool>
    	</features>
</item>

Here’s another example of a clothing and container:

<item
        id = "native.item.backpack"
        name = "Backpack"
        desc = "A strong backpack of hardened leather for carrying ones belongings."
        image = "native_container_backpack"
        weight = "1"
        volume = "480"
        material = "core.material.leather"
    >
    	<features>
    	    <container maxweight="50" maxvolume="480" />
    	    <clothing slot="back" dontime="6" />
    	</features>
</item>

And one more, a ranged weapon:

<item
        id = "native.item.primitive_shortbow"
        name = "Primitive Shortbow"
        desc = "A small bow most useful for hunting."
        image = "native_ranged_primitive_shortbow"
        weight = "1.5"
        volume = "150"
        material = "core.material.wood"
    >
    	<features>
    	    <ranged skill="core.skill.bows" range="60" ammo="arrow" loadtime="0" />
    	</features>
</item>

User Interface

All these XML changes still need to be incorporated into the FMT, but that is a low priority at the moment.  All changes are already working with the engine and things are running as smooth as ever.  This past week, I wanted to play with some of the new item features and so developed a new UI window for when examining items in detail.  Here’s a screenshot of what I have so far with my over-stuffed backpack:

It has been an exciting time for Fief development.  If you’ve been following us on Twitter, you know that the studio is expanding as we welcome JD and Greg as members of the Fief team.

We’ve been working hard on trying to get the game playable again after deciding to completely overhaul the UI and some of the underlying structure.  The new system is coming along, but it is taking longer than I expected.  These changes will make the game far more enjoyable in the long-run and will really help us roll-out the Android version of the game when the time comes.  Here’s an update on each of our progress.  If you want to follow more frequent updates, follow us on Twitter:  http://twitter.com/ArboreanTears

Programming

The UI overhaul has absorbed most my time as I try to reconstruct the various windows and widgets that were available previously, while also fleshing out some new ones.  It might be helpful for me to explain what has been going on and the reason for this massive undertaking.

One of the main limitations with adding new content was the painstaking labor it took to create new user interfaces (UIs).  Each interface was done by hand with no overarching paradigm or binding structure.  As in most early development phases, getting things to work becomes a primary focus.  Only later did I see the flaw as more interfaces needed to interact, despite each individual interface being written in a moment-driven paradigm.  This involved lots of ugly and complex code to get all the pieces to interact properly.  What was missing was an overall framework that was shared between my components.

My previous experiences with Java made me very familiar with AWT and Swing and I wished for a similar graphical solution for Fief.  However, since we wished to maintain support with Android and OpenGL, Swing wasn’t an option for us, unless we wanted to maintain two diverging code-bases and tons of unnecessary overhead.  Since we also use the libGDX framework, there was another option to use the Stage management features it provides.  However, after experimenting with it, it seemed a bit overkill for our needs.  I also didn’t care for its single-threadedness, which made things a bit slow and laggy on slower machines.  I also would have still had to develop a system on the Stage objects anyway to fit my needs.

My solution to this was the Flexible Windowing Toolkit (FWT).  It is a UI toolkit based on Swing that utilizes the libGDX framework at a lower level than Stage management (just a hair above OpenGL itself).  Each individual component is double-buffered and is managed so that rendering only occurs when necessary.  Best of all, the events triggered by interaction with the UI is handled in a separate thread, creating a quick and responsive system.  Some windows can be moved around, locked in place, or snapped into the side of the screen, allowing the player to customize their game environment.  Complex dragging and drag’n’drop operations have a unifying framework that makes coding new behaviors quick and seamless.

I also heavily borrowed concepts from Android when it comes to building the UI at runtime.  All data relevant to UI components are stored in editable XML files, allowing for easy customization of UI elements.  Each element can support 9-patch images as well, even tiled 9-patches (something even Android doesn’t support).

Now that the FWT is stable and working great, I need to convert and reconstruct all our old UI’s to the new system.  The hardest part of this is unifying the way game items are handled.  The new system supports complex drag’n’drop operations with game items.  Currently, I am trying to get all those operations to behave properly and trigger the appropriate behind-the-scenes actions in the game world.  I want to make these operations easy for the player, but still want the player’s character to go through the labor and time of moving objects by hand.

Here’s some screenshots of the work so far.  Ignore how ugly everything is, JD is working on that aspect (see below).  This is currently just my programmer’s art.

Showing the new UI. Examining a tile with the new pop-up window. Top-left is the mini-map. Middle-top is a prototype of the almanac-widget. Top-right is the character status.

Dragging an item using the new windowing toolkit. Acceptable locations are highlighted in blue. The new toolkit supports complex drag’n’drop operations between inventories.

So that is where the programming has largely been going.  It has been a long road, but overall I find the new engine much easier to use than my old stitch-code.  In the future, I am aiming towards improving the survival gameplay.  We have discussed the use of off-manor maps as way to leave the manor and hunt and forage in the surrounding wilderness.  We think that will really improve survivability in the early game before crops and livestock are a viable option.

Modding Toolkit

One more note on the programming front:  I hinted at a secret project awhile back related to Fief.  I suppose now it is time for the big reveal.  I present the Fief Modding Toolkit (FMT; yes, FWT and FMT, it’s confusing).  The FMT is a Swing-based desktop application that will be used to create content for Fief.  It was originally developed as an in-house tool to ensure proper object-linking for new Ruleset data.  It also helps the creator visualize things rather than combing through text files (typos were a common source of errors).  I figured if I made it user-friendly, it could also serve a modding tool that anyone could use.  It’s still largely in development, but we hope to release that in tandem with the 1.0 version of Fief.

Here’s some screenshots to get an idea of the tool:

Sneak peak of the Fief Modding Toolkit (FMT). Here the climate tab is shown where one can modify the biomes that will be generated with new worlds.

FMT. Showing the plants tab, where new plant species can be defined.

Artwork

JD has been working on new designs for the UI windows and widgets.  On Twitter, we showed this mock-up of our ideas for the UI layout.

Mock-up of the new UI for the main game screen.

As you can see from the actual screenshot shown above, we’re getting pretty close.  JD is currently concentrating on the almanac widget (the one at the top of the screen).  Here’s his schematic for the design:

The schematic of the new almanac widget. Temperature bar at the top. Rotating disc showing the time of day, with the current weather in the center. The hanging banner will show the zodiac month.

An example (aquarius) of one of the hanging zodiac-month banners.

Music

Our newest member, Greg, is putting his degree in Music Composition to work.  He is currently concentrating on the music for the title page.  Here are the two samples he has created so far:

Title Sample 1:

Title Sample 2:

He is currently working on a compromise between the two themes and I am exciting by the heroic feelings these compositions invoke.

If you have any comments or questions, feel free to email us:  arboreantears@gmail.com

Cheers!

Here’s the next increment of the Fief saga. Lots of changes in this version and many more exciting things to come.

Hope you enjoy: www.arboreantears.com/fief/download

Changelog: http://arboreantears.com/fief/changelog/

The new character creation screen.

Since it has been awhile since I posted about the fantastic joys of Fief development, I thought I’d update everyone. If you aren’t already aware, I have been using Twitter to report the day-to-day work, but now I’d like to talk about the “big picture”.

The past few weeks has been focused on streamlining the new game process. This included the integration of the world map and generating local maps from this world data. Unfortunately, manor maps themselves may not be as exciting, since they are to be dominated by a single biome. However, I am looking to implement a little bit of travel (primarily for hunting), in which the player’s character can explore other world map tiles. Not sure exactly how I’ll implement this feature, but do not expect to be able to build anything outside the manor map.

Creating a new character is now much more enjoyable. Players get to select many appearance options and finally allocate points into their attributes. Granted, the attributes don’t have a major role yet, but that will change as we add more activities in general. In particular, things like Charisma are awaiting the conversation engine to be completed, and attributes like Willpower and Faith will see their debut when the diplomacy system is in place. But all in due time.

The character background system is now in place and any such backgrounds can be added to the XML. So modders are free to choose the starting skill levels and starting equipment in any such scenario that can be conceived.

When the features listed above are finished (and the bugs squashed), I’ll release the new version. Afterwards, I intend to return to coding survival gameplay and work on making the game actually fun before working on any later-game content.

My work with Fief over the past few weeks has focused on developing job behaviors for peasants and creating GUI tools to allow the player to intervene as well.  I have come up with a basic workflow for how this process will play out.

Most jobs will begin with a request.  The player can make a crafting request on the new Demands page in the Storage tab of the Manor Management screen.  Here’s the crafting request GUI where you can search among all available items:

Here's the item search panel for request items to be crafted. You can search by item name.

Once an item is chosen by the player, it will be added to the manor’s request queue.  Peasants assigned to job sites with the proper skills activated will automatically begin crafting items on this request list.  If an item cannot be made due to unavailable components, a crafting request will be made by the peasant for the component items (automatically placing these requests higher on the request queue).  This can cascade down the line through a series of crafting recipes to ensure that all base components are eventually added to the request queue.  Requests for core resource objects (e.g. wood blocks, branches, etc.) will help modulate the behavior of peasants assigned to such roles that gather these base resources (e.g. lumberjacks, miners).

Here’s an example to illustrate the process.  The player wants a new axe to help chop down some trees.  So she adds the “Primitive Axe” to the request queue.  This triggers the peasant assigned to a job site with the “Survival” skill enabled to attempt to grab the components (Stone Edge, Primitive Cord, Long Handle) and put them together using the “Survival: Tying knots” mode.  However, only the “Stone Edge” is not available in the manor’s storage, so the peasant adds a new request for a “Stone Edge”.  Likely, when the same peasant reassesses their job opportunities, they’ll attempt to create the “Stone Edge”.  However, this too will trigger a request for a Stone object.  Again, the peasant adds the request to the queue, and again will reassess his options.  This time the need for a “Stone” object triggers a stone searching behavior and the peasant will find the nearest “Stone Debris” and gather a good stone for the new axe head.  Once the stone is gathered, the peasant can begin the “Survival: Knapping stones” task to create the “Stone Edge”.  Once completed, the peasant will move on to tying the components together and delivering a new “Primitive Axe” to the manor’s storage.

This is just one example, but I hope this illustrates the autonomy the peasants can have as well as how the player can take an active role in the process, especially if a required item cannot be crafted by the peasants.  In the beginning, the player’s character will likely be the most skilled in many areas.

Job sites are an integral part of this system.  They are where you can assign peasants to varying roles.  The type of job site determines which skills and actions are carried out and how labor is assigned among the peasants at the site.  Peasants at a job site will often have to work together and organize their own efforts to get work done.  This is where the different role types (Independent, Leader, Subordinate) and personalities are important to ensure the work is being done efficiently.

I figured it was about time to release some of the new goodies.  Of course, if you’ve been following along, most of my attention has been centered on behavior and getting some of the early workers up and running.  Since the part is incomplete it is not included here.

The main features of this version are the R-click functionality on tiles, which provide significant information about entities and objects.    There is also the new skill menu with the new fancy icons for each skill.  A number of new skills have been added in, but like many of the skills, they don’t serve a purpose yet.  There are also new icons based on the zodiac signs for the months now.  The big kicker here is also access to the Manor Management screen which will allow you to check out the map.  The area designation process is a work-in-progress, and will likely be changed to something different, but some of its pieces are still available in there.

Hope you enjoy:  www.arboreantears.com/fief/download

Things are moving a little slow since each of the new systems rely on each other.  It is a bit like trying to get a bunch of scaffolds to lean on each other at the same time before they can be bolted together.  So that is where I am at the moment.  The new job site framework seems like it will work as expected and I’ve added some elements to make it easy to assign peasants to job sites.  In the new job site menu you can sort potential workers by name, family name, and skill level in the slots associated skill.  This way you can truly choose the best person for a job, or the best person for training a skill, or just that specific person you wanted to assign to that role.  The following screen shot gives you a glimpse of this, although it’s still a work in progress:

Here's the worker selection box with sorting options. Currently it is sorting by the Forestry skill for all available workers.

As you can see all my test peasants are named “Work”.  I also added a few other features to make getting information about the objects and entities easier.  You can now right click on anything in the game screen to get detailed information about it.  The most important entity gets the forefront of information, such that creatures will override plants and constructions.  Here’s an example of a person standing over a young tree:

Here's the tile viewing window. A peasant is shown with detailed information. The person's current statistics are displayed by bars on the left.

As you can see, I never gave them a proper birthdate, so they are exceptionally old.  Here’s and example of a plant:

Here's the tile viewing window for a plant.

And finally, here’s the player’s character where you can also see objects underneath his feet.

Here's the tile viewing window for the player's character. Also showing the objects that the character is standing over.

As you may have noticed, the peasant has a portrait.  This is not a prepared image, but a procedurally generated portrait based on that person’s data.  Just by looking at a person’s portrait you will be able to get some information about them.  I got the idea for this working with Chernoff faces on a social-communication research project I did as an undergraduate.

The color of their body indicates their rank (peasant-brown in this case). Their happiness is indicated by their smile or frown, as well as their eyebrow slant.  Their nutrition level will be visible based on how wide (fat) their face and body are.  Malnourished peasants will have quite skinny faces, while the well-to-do will have quite a chubby appearance.  The others factors are based on an individuals personal appearance data.  Eventually this data will be based on normal distributions with the means set based on a person’s original kingdom.  Such that people from the same original kingdom will tend to look more similar to each other.  Over time this will be less true as kingdoms are broken, conquered, and consumed into larger ones.  But it will at least help create the illusion of racial origins and culture on the Fief island continent.

So here’s some randomly generated faces.  Each one has a different happiness level, but the same healthy nutrition level.  All other variables were left to vary at the computer’s whim.

The beginnings of faces for the townspeople.

During one of my previous posts on behavior, I promised a sneak peak at the different personality types for the people in Fief.  I wanted to create a model of personality that is both fun, simple, but has a touch of realism.  I also wanted something that had a medieval feeling as well.  The model I came up with is loosely based off the temperaments model of human personality.  

Here’s the list of the personalities, their icons, and the temperaments they are loosely based on.

Personality	In-Game Icon	Corresponding Temperament
Air		Sanguine
Earth		Melancholic
Fire		Choleric
Water		Supine
Void		Phlegmatic

The next table has the interesting portion.  To understand it, I’ll elaborate on how Fief will handle the assignment of labor on the manor.  Traditionally, it is believed, the intricate social structure of the manor largely had the peasants handling their own affairs without much direct intervention from their lord.  They organized their own labor and did the tasks that needed to be done.  Since this is a game, I bend the realism here a bit for the purpose of fun and strategy, so the player will be directly assigning job roles to the peasants.

Job roles can be assigned to peasants at job sites.  Job sites will come in a few varieties: designated areas, buildings, and outliers.  Designated areas are simply zones on the manor map that have a social designation, such as someone’s leased land, the commons, the fields, or a woodlot.  Buildings are structures built for a particular labor, such as a brewery, bakery, or mill.  Outliers are sites of large scale extraction/production of particular resources in the outlying land surrounding the manor village.  These are “off the manor map” locations in the game.  You will not gain access to outliers until the population of the manor reaches the appropriate size, until then, you are limited to the resources on the manor map.

Job sites will have a number of “slots” available for particular role assignments.  These role slots will also have a type based on the organization of labor at the job site.  There are three position types for role slots: leader, subordinate, and independent.  A person in a leader role at a job site will be directing the actions of people with a subordinate role.  Those with an independent role will decide for themselves what to do.  The role assignment will determine what jobs a person performs at a job site and thus which skills will be utilized and improved.

As an example, you could assign a group of peasants to work on the woodlot as lumberjacks.  This woodlot has four slots.  One peasant is assigned as a leader, two are assigned as subordinates, and a fourth peasant is assigned to an independent slot.  The leader will choose which trees are to be cut down and mark them, the subordinates will cut them down, while the independent peasant might ensure there are plenty of new plantings as a manager that isn’t necessarily working with the lumberjacks, but does work on the same job site.

Personality will have a large effect on how well a peasant works in a particular role on a job site.  As shown in the table below, some personalities like being in a particular position, while hate being in other positions.  The focus determines whether a person is motivated by finishing personal goals (goal-oriented) or by socializing with others (social-oriented).  The last column lists whether social interactions increase (extrovert) or decrease (introvert) a person’s social energy.