Games Foundry: Folk Tale Blog: August 2013

By golly a fortnight goes quickly. With everyone focused on their own tasks, the blog presents a great opportunity for the team to step back and review progress across the entire project. As usual, there's a lot going on, including the release of Patch 0.1.6.0 that improved the inventory system.

Save/Load System

The absence of a save/load system at launch understandably generated a lot of forum chatter. Having defined the save/load framework as part of the development of the Location Editor, in the last two weeks we've extended it to include all of the objects in the tutorial. We're about 70% done, with the final 30% involving test cases to check game state is correctly restored. So hopefully not too much longer until players can save games in the tutorial.

With each new patch there is however a chance we may need to purge previous save games. Obviously we'll avoid doing so unless absolutely necessary, but when we do launch the feature, please bear in mind that it comes with a caveat due to the nature of being alpha that the shelf-life of a saved game might only be a few weeks.

Location Editor / Tower Defense Mini-Game

In the previous dev blog we mentioned Aron was integrating the new tile-based navmesh pathfinding system into the Location Editor. In today's blog we're able to take a closer look behind the scenes at what's going on. In the image below, the top and middle windows show the same scene with and without the purple navmesh geometry and the cyan shape-cutters for trees, while the bottom window shows a top down isometric view better highlighting the individual square tiles.

The shape-cutters are required for props that populate a scene, for example trees and chests. We don't know where players will want props in their location designs, so at run-time we perform a boolean operation using the tile's source navmesh and the shape-cutters to produce a new re-triangulated navmesh. If during gameplay the player constructs a building spanning several tiles, the building's own navmesh overrides that of the tiles ( which is temporarily disabled in the event of the building being destroyed ) and connects itself automatically to neighbors. Of course all of this is hidden from players who's focus can remain firmly on creating a great location design.

Tile-Based Navmesh Pathfinding

With responsive UI being critical to user-adoption and productivity, we've been cleaning up the next iteration of UI windows. First impressions count, so it's important resizing, locking, scrolling, snapping and depth swapping are all glitch free to avoid putting players off.

Aron has also been performing a peer review of the entire programming code base. Having been the sole programmer for two years, it's invaluable to get a fresh pair of eyes onto my own code and to implement some of his ideas for improvement.

Art Assets: Hunter's Lodge

Following on from the concept art presented in Dev Blog 10, the three tiers of the Hunter's Lodge are now complete.

Animation: Quadruped Skeleton / Horse Riding

Both the stables and the cavalry military unit require horses be added. Using a rough working model that the art team will later shape to match the final horse concept art, Tom has been working on the quadruped skeleton required to animate the horse. It's early stage but once it's finished we look forward to sharing some video footage of the horses idle, trotting and galloping animation loops.

Quadruped Skeleton for Horses

The same skeleton also drives the deer, which the Hunters shoot with crossbows and carry over their shoulders back to the Hunting Lodge for skinning and filleting.

Concept Art

Pre-production visualizations completed this period include the Stables, Fisherman and Stablehand. A number of the designs are too modern and need a heavier bias towards medieval styling, so they'll undergo a final iteration before 3D modelling begins. Hopefully it will be interesting to show in future blogs how characters evolve from the pre-production sketches we've shared thus far to a final painted 3D character in the game.

I did discuss with our Art Director whether we should produce fully painted concept art pieces from these base visualizations, but I'd rather him spent that time painting the final character texture. It's a much better use of time and money.

Character Concept: Stable Hand

Character Concept: Fisherman

Building Concept: Stables

In an effort to share even more with the Folk Tale community, we're moving from monthly to fortnightly blogs. We've also started to use Google Hangouts internally which has the option to live stream on YouTube. I've previously mentioned in the Steam Forums that I'd like to facilitate Community-Developer hangout sessions, and as part of that I want to share the team's desktops so you can see how Folk Tale is developed. In terms of time frames we hope to start those sessions in November.

Location Editor

One of the most important and fun systems we want to test in the Tower-Defense mini-game is City Walls. In Sandbox you will be able to construct wooden palisades to protect your tier 1 village, and as the game progresses and you gain in power and wealth, stone walls. For the mini-game we're going to focus on stone walls, and throw wave after wave of goblin forces at you.

City Walls

Having built your walls, defensive weapons and traps, the goblins will fling everything that they have at you in waves of progressive difficulty. Eventually you will be overrun, so the challenge is very much to survive for as long as possible.

As you can see in the screenshots below, your walls are going to take a pounding from the Goblin Trebuchet. Your gatehouse will be tested by Goblin Battering Rams, so be sure to mount those turrets with Ballista and Repeating Crossbows. Building a few of your own Trebuchet behind your walls should help take out the Goblins own Trebuchets and Ogres, and putting City Guard/Militia up on the battlements will help take out the goblin infantry who'll be scaling your walls ( covered in dev blog 9 ).

City Walls: Damaged

Further enhancements within the Location Editor include the addition of a randomization feature to provide a starting point to design your locations. Prop Painting with variable brush size is working in a limited form for trees which we'll include in a future video, and Aron has integrated the tile-based navmesh pathfinding system which is very cool, but very technical. Everything is starting to come together.

Character Customization

Adding variety to the appearance of characters was a big request from the RPG fans in the Community. Having previously covered why it's not possible to add the full visual customization found in RPG games ( see the Sandbox Vision Presentation, it's mostly a memory issue ), we've continued our R&D work into what we can do to inject a little more variety.

There were a number of factors to consider when designing our character customization system.

a) Memory efficiency - we need to reuse as many textures and pieces of geometry as possible, and keep textures as small as possible. The fewer assets required to do the job, the better.

b) GPU Draw Calls - A draw call is made to your graphics card each time a material and/or geometry needs to be drawn on screen. If a character has one material ( which comprises of one or more textures and a shader ) that will result in one draw call. Shadow casting adds another draw call, as do any point lights in a scene. It's important to keep draw calls as low as possible.

Being able to swap hair, face, body and props at runtime presents a number of challenges. Each hair style is a piece of geometry, each head shape is a piece of geometry, and each body style is two pieces of geometry ( one for clothing, and one for any exposed skin ). Without optimization, that results in quite a few draw calls ( ignoring point lights for now ):

hair ( 1 geom draw call + 1 for shadows )
+ head ( 1 geom draw call + 1 for shadows )
+ body clothing ( 1 geom draw call + 1 for shadows )
+ body skin ( 1 geom draw call + 1 for shadows )
= 8 draw calls.

Now multiply that by say 100 characters = 800 draw calls just for characters.

Normally RPG games solve this by packing all of the textures for the character into a unique texture atlas for that character, merge all the geometry into one at runtime, and render it with a single material. That reduces 8 draw calls to 2 ( geom + shadows ), but comes with the cost that each character requiring it's own unique texture. A 2048x2048 DXT5 RGBA texture without mipmaps consumes 4MB of memory. Multiplied by say 10 characters on screen at any one time = 40MB in character textures. That sounds reasonable, until you realize that Folk Tale has maybe 100+ characters on screen at any one time, rocketing that total up to 400MB+. Taking the RPG approach simply isn't an option. MMO's solve this problem by instancing public areas to cap the maximum number of potential players on screen at any one time. Again, that isn't an issue for a single player citybuilder game.

For Folk Tale, we're forced to sacrifice a few draw calls to achieve some improvements in memory efficiency. We made the decision that character classes will wear the same outfits to help players quickly identify a character's role ( e.g. Hunter, City Guard ) just by looking at them. That immediately saves us a lot of texture memory. Next, we atlased hair and skin into one texture so that we can combine the hair, head, and body skin geometry into one. Skin, eyes and teeth are left as color RGB, while hair is grayscale. This is because within skin, there are important hue variations that tinting alone cannot capture. Hair doesn't have that hue variation. This however presents a problem because tinting a flesh color limits the color range available. For this reason we added the ability to desaturate the original skin tone in the shader, allowing us to achieve all possible skin colors, from Hulk green to dark elf purple/gray. Packed into the alpha channel of the skin/hair atlas is a mask that determines how much influence tinting will have. Eyes and teeth are masked as black as they never change color, skin is masked as white, hair is masked as white but with ribbons masked as black, and lips are masked as medium gray, because we want them to be only partially influenced by tinting. Finally, we paint vertex color channels in the geometry to determine whether skin or hair tinting should be applied.

Character Configuration ( Click To View Full Size )

What all this technical mumbo-jumbo means is that we are able to merge together the hair, head, and body skin geometry into a single piece of geometry, halving the draw call count from 8 to just 4. Multiplied by our 100 characters and we just saved ourselves 400 draw calls.

The next step is to create the face and hair variations.

Siege Machines and Traps

Having presented the concept art for a number of siege machines and traps in Dev Blog 9, the Art Team have finished modelling and animating the Human Repeating Crossbow, Goblin Trebuchet, Goblin Battering Ram, Goo Trap and Flame Trap. The Spike Trap is done but I'm just not happy with it so I think we'll take that one back to concept.

Concept Art

Concept art development continues, with pre-production visualization of the Butcher and Hunter, Butcher's Shop, Fisherman's Hut and Hunting Lodge all completed in the last fortnight. Concept art remains raw and functional rather than beautiful and polished. Being indie we don't want to spend time and funding prettying up concept art when that's better spent elsewhere.