Storytelling In Folk Tale

by Simon Dean, Project Lead

Folk Tale has undergone a huge amount of iteration and improvement behind the scenes that all started eighteen months ago. In this blog we pause for a mid project review of how we encountered regularly shifting goals, lessons we've learned, and how we'll proceed as we move towards becoming a sandbox game.

The Script

Early on in the project Pete and I held numerous meetings on Skype to discuss lore, back story, and a complete plot that would form the basis of a prototype. Having originally briefed high fantasy, Pete persuaded me to run with gangster goblins, a camp wizard named Camphry Mageflower, and a Mexican wrestler themed end boss with small-man syndrome. Listening to Pete turned out to be a good decision as the humor was warmly received in community previews.

The original schedule allowed for a year during which we would gain familiarity with the chosen game engine to mitigate technical risk, refine production workflows, and build a playable single-level prototype. Given it was a feasibility prototype, I briefed the team to forgo modelling facial features for animation; hand gestures would suffice for expediency. We could always replace the heads at a later date should we need to. The production brief specified low polygon characters by today's standards, as potentially we'd be having a lot of characters on screen at any one time.

As script iterations arrived in my inbox, I needed to cull lines that wouldn't work due to constraints introduced by production decisions. Some of the comedy relied on subtle facial gestures that we wouldn't be able to pull off without facial rigging and a ramp up in the poly count of each character. I think this often came as a blow to both of us, because it meant cutting some really great material.

Storyboard

Initially storyboarding didn't happen in the traditional sense, and that proved to be a mistake. The team was very small, and we lacked the skills and budget to storyboard. Anyone that could have done it was already engaged in producing game content. Being a prototype, it was agreed to muddle through and make the best of what we had as it became available. This often lead to miscommunication, and were it not for the early voice recordings and the script, things could have gotten a lot worse. Having a limited budget to work with often meant corners were cut, and that lead to problems. Part of my job as Project Lead is to anticipate those problems before they happen, and if they do happen, to minimize the impact.

After Jennifer joined the team as Concept Artist / Illustrator and we had actual game content to work with, things improved considerably. We're now able to communicate effectively with storyboards and use game development tools such as Unity to visualize camera angles. Here's the partly-retrospective storyboard that picked up where we'd reached in this preview, and expanded the closing scene with the villagers on the bridge.

'Grim Discovery' Storyboard

Camera Visualization

Pre-Production

With the script signed off, I contacted Sean Ruttledge, a UK comedian with whom I'd previously worked. Sean convinced me he could bring enough variety to the voices to get the job done for a prototype. Sean's early voice development and recordings really helped flesh out the characters, and proved an essential resource for Tom our animator to work against. Scratch voice audio is definitely something we'll do going forward.

Concept art was skipped because the resources weren't available, and we very quickly moved into production. Throughout the course of development, the lack of a dedicated concept artist became a real hindrance not just for cut scene production, but for the game as a whole. In time we addressed that weakness through recruitment.

Production

Tom set to work animating the characters against Sean's lines, doing his best to translate the voice acting into waving arms and nodding heads. Working without scenes he'd render out video clips with proposed camera angles for us to review and iterate on.

All the while in-game content was expanding, and I was able to mockup scenes in game development tools and drop in the animations as Tom delivered them. With cut scenes driven by the actual game engine and programming, many aspects are driven by a scripted cut scene manager to provide control over events in the game world so that they may to coincide with the cut scene. For example, to be able to skip a cut scene by pressing the escape key, we need to ensure that the state of the game world is updated to reflect what happened ( but wasn't watched ) in the cut scene, for example a building catching fire.

Regular team builds allowed us to discuss and further refine animations and camera angles. The whole approach worked well for a while, but as the team's skill level rapidly increased and the game matured visually, it became apparent that the low polygon count and lack of facial geometry and rigging was going to act as a drag on quality. Around about the same time we launched on Steam Greenlight, publishing a few cut scene previews on YouTube. Community feedback started to come in that using only one voice actor wasn't ideal, and characters needed more unique voices. I called a meeting and as a team we reversed the earlier decision, endeavoring to increase detail in character geometry and add facial rigging so we could add facial gestures and lip sync, and expanding the voice actor roster.

Steam Greenlight was a pivotal event that changed Folk Tale from a prototype into a full game production. The new direction would add to the production schedule, but we were excited by what it meant for overall quality.

Post Production

Everything started to come together in early 2013. Lighting was being tweaked and post-render effects added to the camera including color correction, ambient occlusion, bloom, and depth of field. Much of the shader tweaking was already done to support the main game.

I recorded end to end takes of each cut scene with just the final voice acting, and distributed that to Tom the animator who would add facial animation, Oskari the musician who would compose the soundtrack, and Joe the sound designer who would create effects to help sell the visuals.

We're pretty pleased with how things turned out. There's still improvement to be made, but for such a small team, what we've achieved is something we're really proud of.

Final Scene

Reviewing, Learning, and Improving Process

We've learned from our mistakes, and have arrived at a more formal production process. Having acquired two years of experience working with the game engine has really helped our understanding of what is achievable, and what is best avoided in future cut scenes.

Moving to a sandbox game presents an interesting opportunity to take what we've learned so far, and together with our improved process, tackle the task of dynamic storytelling. I can't wait until the game is released proper to write a follow up to this blog.

Designing Game Logos: Folk Tale

by Simon Dean, Project Lead

In preparation for releasing Folk Tale on Steam Early Access next month, we needed to re-design the game logo. Pooling my prior marketing experience and Jennifer's artistic abilities, we set to work designing one of the most prominent assets and documenting the process in the hope it might help other indie developers, or simply be of interest to members of the Folk Tale community.

The Brief

Before any visualization work was started, I prepared the creative brief that Jennifer would be working from, splitting design goals into mandatory ( 'must' ) and optional ( 'should' ) including:

• Must work as a 'rubber stamp' that looks natural when combined with other marketing assets e.g. screenshots, cover art
• Must reflect the artistic style of the game ( hand painted with high detail )
• Must communicate the theme of the game ( fantasy medieval theme )
• Must be reproducible at different scales from large posters to small web banners
• Should work in black and white for reproduction on fax machines ( mostly legal documents )

Typography

With the creative brief in hand, Jennifer set about selecting a number of candidate font faces, and presenting a black and white candidate board for consideration. Typography ( aka 'the font' ) can communicate so much about a product that quite often you'll see game logos made purely from typography without additional artwork. It demands the greatest attention of all elements in a logo, and preparing a simple black and white board helps focus purely on the type. For illustration purposes, here are four fonts that communicate four very different things:

Four fonts communicating very different things

Kerning, line spacing, and weight all needed consideration before arriving at the final font face. We didn't want a lightweight font that was too thin because it would get lost at small scale and not support the 'rubber stamp' goal. The default kerning ( spacing between characters ) was also too broad, so we condensed it.

Styling

It should really have been included in the creative brief, but early on we found that Jennifer would require direction on where within the style spectrum the logo should sit. We didn't want pure illustration which is often more aligned with cartoons and products targeting children, nor does the in-game art style focus on realism. Using other games and logos as references, I was able to communicate the desired art style.

Early Theme Concepts

With our selection made from the candidate fonts, Jennifer set about developing rough theme concepts. As all but one would be throw-away work they were quick and dirty, in some cases pulling from in-game textures.

The team ( representing the target audience demographic of gamers aged 18-34 ) really liked the tree rings texture and green for the leaves; the orange leaves were lost against the brown of the tree ring board. The metal color of the font would introduce an additional resource from the game ( wood, iron, stone, food ).

Concept Refinement

Having identified elements from the early theme concepts that we wanted to take forward, we added a few more ideas and Jennifer set about refining the concept.

We tried different alignments, and settled with a broader offset that would allow us to add a prop. The oak tree further compounded the leaves at the edges of the logo, so this was ruled out because it didn't add to either the 'story' being told or visual impact. The rendered in-game ruin was discounted because it didn't feel right. The sword and shield however developed the 'story' by adding a hint of adventure to the theme. It still felt a bit busy, so we dropped the shield from the design.

Key Design Features

With the final elements chosen and checked against the design goals, it was time to add the detail. Throughout development various tweaks were made, including

• Specular highlights reduced on the leaves to make them less thorn like, reducing the risk of a subconscious emotive response that the game would somehow be painful;
• Detail was left extra-sharp so that it would be retained during the smoothing that happens when scaling down;
• Shadows were added to the leaves to add depth;
• Leaf color variations were added to help the logo blend with various backgrounds such as screenshots. Folk Tale maps have a lot of different ambient zones including snow, lava, green hill, desert, and swamp. The logo needed to blend against all of these without getting lost.
• A subtle drop shadow was added to the text to help lift it off the brown tree ring board
• A black outline was added to text to help readability
• A cyan rim light was added to help color contrast near the shadows
• Leaves were de-cluttered to prevent obscuring the text
• Consistent directional lighting was added
• Bloom was added to enhance the metallic feel of the text
• The cooling blue hue was added to metallic elements to help differentiate them from the warm natural hues of the leaves and wood

Testing

A final round of testing was performed to check for any scaling issues, and to validate the logo would work in nearly all scenarios.  Below is but one of the test slides.

Minor refinements were made during testing, and three weeks after the initial meeting, we had our final logo:

About Folk Tale

Folk Tale is a fantasy city-builder strategy adventure game for PC, Mac and Linux developed by indie studio Games Foundry. For more information, please visit www.gamesfoundry.com.

Look Yonder Bernard, There Be The Future

by Simon Dean, Project Lead

Previous blogs have covered how Folk Tale came to be developed as a single player mini-campaign demo, and how talking with our community has helped us to better our understanding of the features you want the most. Time now to look beyond our upcoming Kickstarter to what we plan to deliver. The best place to start is with our revised elevator pitch and a walk-through of how play might progress during a session.

Folk Tale is a sandbox fantasy city builder strategy game in which you lead a ragtag band of peasants in growing a small settlement into a thriving market town, while the dastardly Slavemaster Urzal and his minions plot your downfall. Sound the rallying call and head out into the wilds with parties of heroes and fight back the tide of evil in a game of endless possibilities.

Rule with tyranny and oppression, or liberalism and justice. Play as a merciless expansionist hell-bent on destruction, or as a gold-hoarding mercantilist who'll sell their own grandmother. With random events and dynamic story, in Folk Tale you never know how the story will unfold.

For gamers wishing to draw parallels with other games, you might describe it as a real-time fantasy take on Civilization mixed with Age Of Empires, The Guild 2 and The Sims in a game focused on building of a single detailed city where you can walk the streets shoulder to shoulder with your subjects.

At this point we should add a disclaimer that during development sometimes it becomes necessary to redesign or even remove features for technical or commercial reasons. This blog is a vision statement of what we hope to deliver. The final version of the game may differ in some aspects from this vision. When our Kickstarter campaign begins, we strongly suggest reading the understanding risks section.

Pre-game begins with you choosing from a wide selection of scenarios ( including launch designs by the Folk Tale team and rated community scenarios ) and tweaking the type of game you wish to play by choosing overall difficulty, ferocity of AI ( docile, roaming, aggressive ), climate, resource scarcity, dungeon frequency, and so on. By providing as many options as we can you can choose settings to match your preferred style of play. Advanced players can use the editor to design your own maps, share with friends, or share with the whole community. We'd like to point out that any online features such as downloading user generated maps would require an internet connection, however previously downloaded maps would be able to be played offline.

With game settings tuned, the world is created/loaded and play begins.

Starting out with a handful of peasants, your early tasks include constructing simple cottages, establishing farms and fishing for food, and scouting the map for valuable resources used to expand the settlement. With aggressive AI, roaming enemies that grow more challenging over time may cross your path or even attack your village, so with the help of a village Blacksmith you can craft new gear with which your inexperienced peasants can protect themselves, or unlock the Barracks and start training militia.

Venturing further into the wilds with a better equipped party, you'll soon discover a dungeon to explore. If you've established a Thieves Den in your settlement ( later evolving into a fully fledged Thieves Guild ) that thief you brought along with you should come in handy spotting hidden traps and devious puzzles. If not, you'll have to find other ways to get around the challenges. Tackling the dungeon and vanquishing any foes stupid enough to block your path, you emerge victorious with a hoard of magical loot that can be equipped, sold at the travelling bazaar, or transmuted into resources used to craft another magic item. For that though, you'll be needing Wizards.

Growing in prosperity, a few of your subjects have been busy upgrading their cottages. Proud of their new possessions, they've been showing off some of their finery to their friends in the marketplace. That's caught the attention of the Thieves Den, who have set in motion a plan to relieve some of that new found wealth. It's down to your City Guard ( militia ) to investigate, reveal the perpetrators and stamp out the crime wave before it becomes an epidemic.

No longer satisfied with staple food and supplies, the emerging wealthy class will soon be demanding more exotic foods, clothing and jewellery, so you best set about adding more advanced economic buildings. Ignoring the needs of your subjects will cause increased unhappiness, and before you know if you'll have a riot on your hands with angry citizens setting fire to things. Let's hope you've sunk a few wells nearby, otherwise its a long run with pails of water by which time only smouldering embers may remain.

With a vibrant and growing town on your hands, those early resources will soon be depleted, so it's time to head deeper into the more dangerous parts of the wild. Before you do, you head over to the Tavern and share a tankard of mead with locals while listening to a performance of "You're Bard!" Looking around you grease a few palms with coin and hire a hero or two to bolster the ranks of your militia.

Deep into the wilds, and your band of merry folk pick up the trail of a goblin hunting party, leading you into the swamps for your first encounter with the goblin nation. It could go one of two ways depending on your actions so far. You might be able to ally with the goblins and establish trade routes ( for players preferring a more peaceful game style ), or insult their Leader and start a war.

Cause and effect will be a big part of Folk Tale. The actions you make will impact your future options. If you dish out harsh punishments for the pettiest of crimes, your subjects will quiver in fear as you walk among them and consider leaving for good, but there sure won't be any stealing. Rule with liberty and justice, and your town will be a happy place but with social problems. Follow a course of merciless expansionism and you risk open conflict, or be a merchant extreme with the goal of amassing a vast fortune, at the risk catching the attention of the Thieves Guild or the ire of jealous merchants. With random events and dynamic story, one of our design goals is to make each game different from the last.

New Terrain Engine and Map Editor

For the demo we pre-designed a large terrain encompassing several environment zones including arable farmlands, volcanic, snow, desert and swamp to show the rich variety of landscapes players can expect in Folk Tale. However, the way both terrain and pathfinding are implemented for demo no longer support our revised vision of including a map editor that we can easily update via downloadable content updates. Instead, we are going to migrate all the environmental assets developed so far into terrain blocks that can be placed, rotated and grouped together in a map editor. While this will change the appearance of terrain to have more of an RTS feel than open-world RPG, the customization benefits it brings should be significant.

Character Customization and Equal Opportunities

We've completed preliminary research and development into how we can add visual variety to characters. We plan to continue that work with the goal of adding height, weight, hair and skin tone variations, as well as looking at the inventory system and how that might add to visual variation without detracting from the need to quickly identify a character's occupation from a distance.

One of the tasks for demo that we didn't have time to complete was equal opportunities for male and female peasants.  At the moment occupational roles are restricted to either males or females.  This isn't a design feature, and all occupations within the game will be open to both sexes once we've created the required assets.

Dungeons

Being able to delve deep into dungeons has long been on the list of features we'd like to add; but it also represents a major amount of work, especially to produce all the environmental art. So explorable dungeons are likely to become a funding "stretch" goal, left until towards the end of development, or added as DLC funded by sales.

Content Reuse, Updates And Phased Release

Having spent the last two years developing Folk Tale, you could be forgiven for thinking that it'll take us another two years before anything gets released. I'm glad to say that will not be the case for two reasons: we've already made a lot of assets and coded many of the core systems including inventory, cut scenes, construction, and questing.

Post-Kickstarter backers will receive access to the demo providing a taste of game mechanics, story and humor. We hope backers will provide feedback on how they think the game should evolve within the context of the plans set out in this blog, during which time we will be prototyping the new terrain system and map editor. We'll share that as soon as a stable build becomes available, and follow up with an update that migrates the demo to the new system, incorporating any new content that the art team have been working on.

All our efforts will be focused on developing the sandbox game mode for the final release, providing regular build updates throughout the course of development to maintain transparency, and involve backers in the decision making process. Having shipped the final release, funding and revenues permitting, our attention will turn to expanding content through DLC and adding additional game modes.

Always-On DRM, No Thanks

A hideous feature that shall one day be cast into oblivion. We have no plans of adding always-on DRM, and players will be able to enjoy Folk Tale in offline mode. There will be a key activation system during development, and the usual security wrapper added by Steam and other digital distributors.

Hopefully we've gone some way in clarifying what the future holds for Folk Tale. We welcome your thoughts on our plans, and hope you will consider supporting us during our upcoming Kickstarter campaign.

Beta Signup and Monthly Newsletter

To keep informed with our progress and upcoming Kickstarter campaign, you might like to consider applying for beta and opting in to receive the monthly email newsletter.

Help Folk Tale Win The Indie Dev Grant

Until 1st April 2013 Folk Tale needs your help in giving us a shot of winning an indie dev grant of up to $1000. Read about how with just $2 you could help charity, indie developers, Folk Tale, and grab a bundle of fun games all in one go.

Designing UI For Hybrid Genre Games

by Simon Dean, Project Lead

When we first sat down to design the UI, we gave a lot of consideration to the types of players that would be experiencing Folk Tale, and the information needs each of their play-styles has. Combining the genres of city building, real-time strategy, and RPG, there was a risk of information overload and failing to deliver a positive gaming experience. Players gravitating towards the action found in the RTS aspects of the game might be put off by the depth of information a strategy-biased city-builder player might be accustomed, or the level of character detail and customization enjoyed by the RPG player. We set about analyzing the aspects of game play from each genre that would feature in Folk Tale, thought patterns players would have during decision making, and key data and functionality required to reach and execute those decisions before categorising everything into tiers.

Starting Simple, Iterating, and Ramping Up At The End

Being acutely aware that games attempting to span multiple genres sometimes strive to achieve too much, development of Folk Tale is deliberately an iterative process. Features are added and removed on the premise of natural fit, or dropped entirely if time pressures mean they are unrealistic to implement. An example that springs to mind was whether or not loot would fly out of corpses as 3D objects ( diegetic ), or if the player would loot by opening an inventory comprising of icons ( non-diegetic ). The UI demands of each implementation are very different, and regularly shifting design goals present a challenge for interface design tasks running in parallel. Rather than invest time in painting pretty UI early on, we adopted a simple vector-shape based approach to block out UI. Not only did this enable us to get any early feel for how much screen real-estate would be occupied, it allowed us to quickly test the flow of interaction. One of the early prototypes featured a "bottom heavy" design, occupying the entire lower section of the screen. We soon realized this was too clunky with a lot of wasted space. The decision to throw it out was made easier by the limited time spent on the layout.

Commercial Reality

As it turns out, decisions affecting other areas of development were causing anticipated slippage and resulted in a commercial decision for demo that the loot system would be non-diegetic, thereby reducing the burden on the 3D art team who's time was required elsewhere. The decision coincided with Jen joining the team as concept artist, and she kindly agreed to hand paint a consistent set of icons for loot and skills before resuming normal duties post Kickstarter.

Icon Design

Layered Icon Workflow In Folk Tale

With iteration and change inherent in our development methodology, Jen and I designed a layer based production approach to icons, separating out background ( typically a gradient fill ), background fx ( swirls, magic sparkles, smoke ), mid-ground icon and halo, foreground fx, highlight and rim light. This would allow easy re-coloring should it be later required. To support re-framing, Jen would also paint complete objects rather than taking the shortcut of painting only the visible parts of a fixed composition. And finally it made sense to work at a higher resolution and resize down to the final icon size ( a consistent 47x47 pixels used in all UI windows ) to future proof for devices with ever increasing display resolutions such as iPad 3 and 4.

Designing For Accessibility

Learning from web accessibility initiatives, there are a number of simple things we added during interface design to help improve accessibility. Simple things like providing a pause button and subtitles during cut scenes, and allowing players to experience play at their own pace and difficulty can increase satisfaction instead of contributing to frustration. Gaming has it's own set of accessibility requirements beyond those of the web, such as keyboard remapping and mouse inversion to help left-handed Gamers. While budget may prevent us from doing all that we can especially for demo, accessibility certainly factors in every design decision.

Painting The UI

With the important decisions made and the feature set frozen for beta, we were able to commit to the final paint over. With a tight budget prior to our Kickstarter campaign, we aren't able to add all the functionality we have planned for the final UI ( such as customization ), but hopefully we've added enough to effectively communicate what you can expect in the final release.

The Final UI Design

Spacial Elements And Data Tiers

With so many data generators existing in the game world ( characters, buildings, natural resources, interactable objects ), an early part of the design process involves looking at use-case scenarios to identify data and functionality the player needs to support decision making and execution. Where data is required from an object, data generators are assigned as spacial elements on demand, projecting their data from the 3D game world onto a 2D UI plane that sits beneath the main UI, and only for the duration they are within the camera frustum and within range. The moment a spacial element leaves the camera frustum or goes beyond a distance threshold, the element is recycled in a UI object pool.

Consider a zoomed out panorama that takes in most of the village. It represents a macro view of world events where the player is most likely occupied with big decisions such as town planning or the movement of groups of characters. Taking the latter as our use-case, if the player is moving a group of characters from one location to another, they aren't interested in the detail of each character. We can discard irrelevant data and functionality such as character attributes, names, and access to individual characters skills. In fact, the use-case simply requires that we communicate which units are selected. We can still communicate valuable information in a condensed space for other use-cases ( for example if this was a combat manoeuvre ), so each character receives a mini-status icon above their heads showing the characters health and power, and in some situations an icon showing what that character is up to if it is something important. It's better to provide the player with a visual cue with shape and color than to display text indicators. So for wounded characters, the health bar should change to red instead of green instead of showing "13/50".

Advancing the game a little, the player issues a group move command, and then decides they want one of the characters to split from the group and go somewhere to be trained in a profession. The use-case changes, requiring more UI to execute the decision. Have I selected the right character? Are they a peasant without an occupation? Are they busy doing something of value and should not be interrupted? Do I need to take corrective action before sending this character for training, such as healing them? These are all potential thought patterns that occur within milliseconds, and our goal is to make sure the data required to answer those questions is immediately available, and unpolluted by anything irrelevant. We still show the mini-status bars to indicate which character is selected, but the more detailed action bar for the character pops up showing a zoomed in portrait for visual confirmation that the correct player was selected, name, level, key skills and commands. We haven't overwhelmed the player with data such as character attributes or inventory, because it would be irrelevant to the use-case. Tiering data in this way allows us to quickly match information to use cases.

I hope you've found this blog an interesting insight into the thinking and workflow that has gone into designing the Folk Tale interface.  If you have any questions or comments, I'll be happy to answer them below or on our Facebook page.

Beta Signup and Monthly Newsletter

To keep informed with our progress and upcoming Kickstarter campaign, you might like to consider applying for beta and opting in to receive the monthly email newsletter.

Help Folk Tale Win The Indie Dev Grant

Until 1st April 2013 Folk Tale needs your help in giving us a shot of winning an indie dev grant of up to $1000. Read about how with just $2 you could help charity, indie developers, Folk Tale, and grab a bundle of fun games all in one go.

From Rags To Britches

by Rich Sanders, Art Direction

For the past few weeks I’ve been reworking one of our oldest assets, the goblins. These devious antagonists were created almost two years ago during which the art style of Folk Tale has evolved, leaving the goblins stylistically out of step with the rest of the game’s aesthetics. With the Kickstarter campaign fast approaching, our main objective was to keep production time down by giving them a rockin new paint job and reusing a lot of the existing model geometry.

Ermahgerd What’s Wrong

To start the process I needed to identify why these models felt inconsistent. It was obvious that our texturing skills had drastically improved since we first started on the project, but the villagers are old as balls too and they still fit in. One of the most noticeable issues to me was their eyes. The problem was partly stylistic and partly due to Folk Tale’s scope two years ago. In any case, they had this weird “You sure got a purdy mouth” kind of expression.

The skin and clothing texture also needed stylistic changes. It consisted of mostly large forms that described the character’s muscles and features predominantly with an overhead RTS style camera in mind, but it wasn’t holding up in cut scenes or first person camera mode where the camera can get much closer. Smaller details would need to be added to focal areas like the face in order to look good up close. Through trial and error we found that our characters looked better with a more incandescent shader to hide the nasty little dark areas low polygon geometry produces in real-time lighting, and to help them pop when ambient lighting has a heavy blending effect. However, with greater incandescence, we now had to paint stronger shadows into the texture to counter the weaker real time shadows. Since the old goblin texture had hardly any painted shadows they were looking very flat in game.

Base Paint

The original textures were an excellent starting point, essentially acting as 3d concept art. First, I decided to created a mostly nude goblin texture. All the goblin models had identical UV layouts, which meant I could make one goblin birthday suit that would fit them all.




I typically approach a skin texture like this by roughing out the anatomy with large forms that describe muscle groups, then slowly working down into smaller details such as veins and wrinkles. Certain areas such as the wrist, waist, and lower legs were covered on all the characters, so to save time I skipped over these parts. It’s always a good idea to steer clear of a goblin’s rear end whenever possible, amirite? I’ve also incorporated some principles picked up from Valve’s amazing Dota2 Character Art Guide, such as using value gradients to make characters quickly identifiable. The value gradient, or the range of lightness and darkness in our color palette, has to be kept somewhat clamped in Folk Tale. Values too close to absolute white become overexposed, values too black lose color and definition when applied with real time lighting. By using the value gradient scale, this method works great to create focal points, help give the objects a more three dimensional feel, and establishes that all the goblins have unified values.

Variations

With the basic skin done it was time to start making each character unique. The warrior was a natural place to start painting because he had pants, gloves, and boots that covered the most surface area. I could use his texture as a base for the rest of the characters to save time. My approach to color was to stick with the original earthy palette of browns and greens, while adding small amounts of secondary and tertiary colors. Once the clothes and armor were complete I manipulated the skin hue to differentiate each character even further #cheating. 

The last step for these characters was to produce a specular map packed into the alpha channel having recently introduced specular maps into our character shader to counter the dull look metal would have in some lighting conditions.

Props

When reviewing the goblin props, there were two main things I was interested in: does the model’s geometry look acceptable when viewed up close, and does it have a strong silhouette. Silhouettes play a large role in making a character easily identifiable. For dominant props, such as the warrior’s axe, I used more exaggerated, curved, and tapered shapes to increase its visual appeal.

This however, did require some items to be completely remade. Luckily these props were fairly simple and could be remodeled reasonably quickly. Creating a new prop starts with a quick black sketch to nail down the core idea and shape. Then that drawing gets put into a 3d program (I use Maya for this) where I can use it as a modeling reference. Once the models complete, the model is brought into Photoshop to texture and paint the weapon in the same manner as painting the goblin body.


Beta Signup and Monthly Newsletter

To keep informed with our progress and upcoming Kickstarter campaign, you might like to consider applying for beta and opting in to receive the monthly email newsletter.

Help Folk Tale Win The Indie Dev Grant

Until 1st April 2013 Folk Tale needs your help in giving us a shot of winning an indie dev grant of up to $1000. Read about how with just $2 you could help charity, indie developers, Folk Tale, and grab a bundle of fun games all in one go.

Help Folk Tale Win The Indie Dev Grant

by Simon Dean, Project Lead

As an indie developer we're always on the lookout for funding, and last week I happened across a great initiative called the Indie Dev Grant:

The Indie Dev Grant is a grant designed to help indie game developers create their games. For every 100 bundles we sell, $15 will be added to the grant. 5% of sales goes to charity, and 75% to the developers of the games in the bundle. One indie developer (be it a group or an individual), voted by the esteemed fans of Bundle in a Box will get the whole amount after the bundle ends.

We've entered Folk Tale as a candidate, but there's some stiff competition and we need your help.

We'd like you to consider buying a bundle of indie games for $2, click the link in the confirmation email, and vote for your preferred candidate e.g. Folk Tale hint hint. The winning candidate of the indie dev grant ( hopefully Folk Tale! ) receives a grant of up to $1000.

I bought my bundle on launch day, and there's plenty of entertainment value to be had for your couple of bucks while at the same time helping charity and indie developers, and giving Folk Tale a shot at winning the grant.

UPDATE:
Day 11 of 13: Folk Tale remains in 2nd place, 10 votes behind 1st place and 7 votes ahead of 3rd place. This opportunity isn't just about the grant, its about the PR exposure, so we'd really appreciate your vote if you haven't already. There's a one-on-one First Impression session with Folk Tale's Project Lead up for grabs for one lucky winner. Be among the exclusive few to experience Folk Tale before our Kickstarter campaign and win alpha access!

How To Vote

1. Visit http://www.bundle-in-a-box.com/ and click the orange Buy Now button.
2. Pay with either Paypal or Google Checkout.
3. Open the confirmation email and click the link ( I've shown mine below )

4. This will take you to the download and voting page as shown below:

5. Scroll down to find Folk Tale in the voting list, then scroll down to the bottom of the page and hit Vote.

6. If you would like to enter the draw for our March 2013 email newsletter competition to win a Folk Tale First Impression VIP one-on-one session, simply sign up for beta then drop us an email to info@gamesfoundry.com with the subject line 'Bundle In A Box: First Impression Competition'. The competition closes midnight GMT on 2nd April 2013 and is governed by the laws of England and Wales. The winner will be announced in April's email newsletter. No purchase is necessary.

Once you've been through the process once, if you really love what we're trying to do on Folk Tale, you might consider buying a code or two for a friend.

Thanks so much for your support!

Obligation, Honesty And The Road To Kickstarter

by Simon Dean, Project Lead

Making The Game You Want.

Over the last six months we've had the opportunity to engage with a growing community to better our understanding of what Folk Tale should be, and how that differs from what we've built as a demo. Some of you may ask why we didn't just do that on day one, but with little awareness and a community the size of which you could count on your left hand, there was nobody to ask. So for nearly two years we've been developing a single-player mini-campaign to act as a taster of the world of Folk Tale. It turns out we were wrong, but only slightly.

With a small development team and the assumption that we raise only our minimum fundraising goal, our ability to deliver the entire scope of Folk Tale at launch is limited. We have to take a smart approach, so we asked everyone through our Steam Greenlight and Facebook pages the order in which game modes should be prioritised with a view to staggering releases.  Your answers - sandbox (289), campaign (230) and multiplayer (127) - proved incredibly helpful and enabled us to make the following observations:

• Replayability is essential;
• The fewer constraints on game play the better - let us play how we want to play;
• Single player features are more desirable than multiplayer in games such as Folk Tale;
• Story is entertaining and provides a learning opportunity before advancing to other game modes, but offers limited replayability;
• For multiplayer, co-op is more attractive than PVP;

This insight coupled with the benefit of two years production experience leads us to a logical conclusion: develop Folk Tale as a sandbox game with random events within a dynamic story framework that utilize limited cut scenes.  Once we have a solid single player game, and funding permitting ( which by that stage should be supported by sales revenue ), expand via DLC to add new content and cooperative multiplayer.

Two Years Of Preparations.

While the norm for Kickstarter projects is to present early stage concept art and WIP videos after only a few months of work, we've gone far beyond that and produced a polished feature rich demo that includes a lot of mechanics and UI from the final game.  It's taken significant investment and risk-bearing on our behalf, but we feel there are good reasons to do so:

• Risk mitigation
  
  There were a lot of unknowns when I first started on Folk Tale. Before trying to attract a team of collaborators, I felt a duty of care to ensure we could deliver.  That ethos continues throughout development, and only by completing a feature rich demo will we know for sure that few technical challenges remain that could trip us up.
  
  Unfortunately not all projects share that ethos, and Kickstarter is starting to see the occasional funded project fail before completion, possibly because of poor technical and financial risk management or leadership. That hopefully won't be an issue on Folk Tale because of a policy to mitigate quantifiable risk early on, and professional experience.
  
  The team has done a huge amount of work up front to establish credibility, enabling us to deliver a complete mini-campaign to backers immediately after Kickstarter. Rather than starting from scratch we will be heading into our Kickstarter with optimized game code, significant volumes of content already made, and established production workflows that make it far easier for us to execute our delivery plan. Now it's all about scaling out to produce the content by funding more of the team on a full-time basis.


• Kickstarter fatigue and the need to stand out
  
  We suspect fatigue is affecting smaller scale lower quality projects and funding is migrating towards larger more credible projects.  While delivering quality and broad scope requires more resources and funding, what we are presenting will hopefully help differentiate us from the other campaigns that will be running in parallel with ours.


• Demonstrating commitment, willingness to share risk, and an ability to deliver
  
  As potential backers you will hopefully feel more at ease knowing you are funding a team that has been together for two years with a demonstrable commitment to delivering quality with effective leadership. A team who believes in what they are doing strongly enough to have risked a lot of time and savings before asking for funding.


• Establishing a trust relationship
  
  We've been very active in establishing regular communication with the community through social media, email newsletter, and this blog.  Not only does that help spread awareness, it contributes to building trust.  We need to earn and respect your trust if we plan to ask you to support us with funding, and that starts with a policy of transparency, communication and ethical behaviour.

In the coming weeks as we continue our preparations for Kickstarter, we'll be sharing our plans for revised features, and when you might expect them.  In the meantime, to keep up with the latest news, you might like to consider opting in to receive the monthly newsletter and register for beta.

If you enjoyed this blog, please consider sharing it with colleagues and friends. As an indie team we need all the help we can get in spreading awareness. Thanks for your continued support!