Pages

Wednesday 20 March 2013

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
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.

Thursday 14 March 2013

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!

Saturday 9 March 2013

A Tale Of Toast, From Crumbled Beginnings

by Simon Dean, Project Lead

With the two year anniversary of Folk Tale development fast approaching, its an opportunity to look back at the game's humble beginnings, and examine some of the decisions that have caused delays along the way.

The first few months of the project were spent in isolation learning the intricacies of the engine and assessing project feasibility. I knew the project would need to raise funding to complete development so I planned to tackle most of the technical risks up front to build credibility and demonstrate an ability to deliver. While my programming skills were decent, many of my other skills were rusty having laid dormant since leaving the games industry fifteen years prior. I very quickly realized I needed help, so with a prototype held together with nails and glue I shared my progress in the game development forums.




The Early Folk Tale Prototype

Playing the first build again - which in reality means walking around a small area watching some very basic pathfinding – I'm surprised at how much potential it showed. The prototype was good enough, and over the summer of 2011 the team grew in size with collaborators joining from the United States, UK, and Europe.

By late summer 2011 Pete had joined the team as a writer and had become instrumental in driving the story and humor of the game forward. As an author of zombie-themed short-stories, I had no idea whether Pete could turn his hand to lighthearted comedy or not. Reading his first few submissions, I admit I struggled with letting go of the remnants of high fantasy present in the early prototype and adopting gangster goblins, camp wizards, and a faith based on the worship of toast. But the more drafts Pete scribed, the more I became sold on his vision. All his great ideas however presented a dilemma. How could our small indie team with just one animator handle the volume of animation work required to effectively tell the story. Slashing admittedly great work to reduce the length of each scene, I bit the bullet and committed Tom our animator to the huge burden, knowing it to be the first decision that would significantly push back the delivery date. With a whopping ten cut scenes in the demo, in hindsight it wasn't something we should have tried to tackle.

How did we go from a gritty looking medieval scene to the colorful world of today? Folk Tale was going to be a humorous and entertaining game, and that didn't fit particularly well with the semi-realistic art style of the prototype; the early characters produced by the artists had more of a WOW look than life-like; and on a technical level we could keep shaders computationally inexpensive by avoiding normal maps thereby helping performance. Weighing all the factors, the decision was made that we would migrate towards a hand-painted art style.

That process wasn't immediate, evolving over the course of the following year through trial and error. Without a concept artist to call on, the creative process started with me as Project Lead creating reference models or annotated image mash-ups, before being handed over to the artists to contribute their own ideas. Briefing multiple artists this way was problematic. While there was a convergence of style, there were slight inconsistencies between assets due to each artist's skill level and interpretation that would persist for another year.


Village Life As It Exists Today


Eighteen months in, and the team had settled into a workflow that while not perfect, was yielding consistent results thanks to each member focusing on tasks that played to their strengths. Project quality had improved significantly, and the only inconsistencies that remained were in the textures. We could have overlooked that, but knowing we'd be asking the community to help fund the game, we felt a duty to strive for perfection. To help address the inconsistency issue, Rich assumed responsibility for art direction overseeing the production of all models and textures, a timely appointment as Hayden joined the team part-time as a 3D artist. Tom was assigned ownership of all technical art ( skinning and rigging ) and animation. With Rich finishing an excellent remake of the snow covered Monastery Of The Mangy Wolf , and Ben finishing a similarly great job on the volcanic Old Forge area, the Goblin Swamp was now looked sparse and was showing it's age having been the first zone to be modeled many months ago. So we expanded the scope of Rich's assignment to include not only a repaint, but the remodeling of all the swamp assets, and that required more time.

In September 2012 Steam Greenlight launched, and propelled Folk Tale from obscurity into the limelight. Everything snowballed and after 104,000 visitors with 67% voting "Yes", Folk Tale was greenlit in the second round of selections on October 15th. The comments came in thick and fast as the unique visitor count continued to climb towards the 200,000 mark, providing us with valuable early feedback. One of the recurring observations was that our initial plan to use just one voice actor for all the characters wasn't going to cut it. With zero additional budget for voice acting, I turned to the voice acting alliance forums and shared what we hoped to achieve. The response was tremendous, and after receiving around thirty auditions in just 24 hours, we closed the post and selected ten talented performers to work with. As a community request-verging-on-a-demand, it wasn't on the project schedule. Coordinating legal contracts, recording sessions, processing, editing and slicing hundreds of lines of dialogue over several months was extremely time consuming and diverted many hours away from development, further adding to slippage.

Expanding the scope of assignments did however have a positive outcome in that I personally gained some much needed breathing space to cope with ever-increasing demands on my time. As project awareness increased each of my responsibilities - programming, design, team leadership, marketing and business - all ballooned. The success of Greenlight had unexpectedly forced us to up our game on a number of fronts. Our marketing communications had been somewhat limited to the standard-fare of social media, so I spent Christmas writing our email marketing platform with the inaugural email going out as we welcomed in January 2013. Then there was the increasing globalization of our community requesting the game be available in multiple languages. With the original plan only allowing for English and lack of budget once again an issue, I turned to the community and set about writing the Community Translation Tool. It would of course be easy to ignore such requests, but that would spoil the best part of what it is to be an indie; being able to interact with Gamers on a one-to-one basis and inviting them to share in your passion. Spending the extra time means the demo will be that little bit better appealing to a larger audience, and we need every win possible to maximize our chances of a successful Kickstarter campaign when it starts this spring.

The reality of why the project is taking longer than expected is a simple one: a small team with limited budget striving to deliver something exceptional leaves only one variable: time. If we let any aspects of game development slip, we risk not reaching our funding goal. Taking a little longer than planned and maximizing our chances of success is the right decision for everyone.


Beta Signup

For those of you visiting for the first time, applications for closed beta are now open.  Please don't forget to opt in if you wish to receive the email newsletter.