UI Updates

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.

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

Screenshot with most of the new UI elements.

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:

Name Description Status  Pic
Container Window Show the contents of a container. Complete pic
Character Status Widget Shows character status and conditions. Complete pic
Equipped Items Widget Shows items in hands with swap button. Complete pic
Message Widget Shows game messages with optional minimal version. Complete pic
Action Bar Widget Shows current action and remaining time. Complete pic
Mini-Map Widget Shows small map of the area. Complete pic
Inventory Window Show character inventory for interaction. Complete pic
Recipe Browser Window Show and browse all available item recipes. Complete pic
Construction Chooser Window Show and browse all available constructions. Complete pic
Construction Phase Window Show components for a construction phase. Complete pic
Menu Widget Show buttons for quick access to game functions. Complete pic
Options Menu Game options pop-up window. Missing artwork pic
Crafting Window Add objects for crafting new items. Missing artwork pic
Examine Window Show elements in selected tile. Near complete pic
Item Info Window Show details about an item. Near complete pic
Action Button Widget Show available character actions. Redesign pic
Skill Action Button Widget Show available skill actions. Redesign pic
Skill Tracker Widget Track XP for marked skills. Concept
Item-Chooser Window Menu for pickup/moving objects to choose items and quantity. Concept
Construction Window  Shows construction modules with interaction panels. Concept
Announcement Window  Show and browse in-game announcements and notifications. Concept
Help Browser Show and browse all game content and concepts. Concept



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:

Module Name Description
Wall Construction can block movement and sight.
Window Construction can block movement but not sight.
Door Construction can limit access to specific people.
Enclosure Construction provides safety from weather (e.g. tent).
Container Construction can store items.
Liquid_Tank Construction can store liquids.
Furnace Construction can provide heat by burning combustibles.
Crafting Construction serves as a workshop for crafting.

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:

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:


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:

Item Feature Description
Ammunition Item can be used as a projectile for ranged weapons.  Can define type  (i.e. arrow or bolt) and damage type. Also can specify cartridge-like ammo with multiple uses per item.
Armor Item provides protection against specified damage types by reducing the severity of attacks.
Clothing Item can be worn in an inventory slot.  Can define time it takes to don the clothing.
Container Item can store other items with limited weight and volume restrictions.
Food Item can be consumed providing hunger and thirst points.
Light Item is a light source when in use (in hand). Can define range and color.
LiquidTank Item can store a liquid with limited volume.
RangedWeapon Item can fire projectiles. Can define range and projectile type.
Shield Item can be used in the off-hand as a shield for blocking.
ThrownWeapon Item can be thrown at nearby enemies.  Can define range and damage type.
Tool Item can be used as a tool for specified skill modes with specified modifiers.
Weapon Item can be used as a melee weapon in combat with defined damage type.

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

Special Feature Description
Corpse Item is actually the corpse of a specific creature.
Seed Item is actually the seeds of a specific plant.
Skin Item is actually the skin of a specific creature.
Unfinished Item is actually an unfinished crafting project.

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

Here’s another example of a clothing and container:

And one more, a ranged weapon:


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:

Item Info Window

The Long March to Playability

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


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.

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.

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.

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.

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



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.

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.

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.

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



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



New Game Streamlined

The new character creation screen.

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.