Modules

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

Bookmark the permalink.

Comments are closed