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!