I am excited to announce that Eastshade will be showing in the PAX West Indie MEGABOOTH here in our home town of Seattle! We’ll have a station in the MINIBOOTH September 2-3. Check out the full MEGABOOTH line up here. Hope to see you there!
Photo by Official GDC
Huzzah! We have most exciting news! Jaclyn and I will be at GDC this year showing a playable build of Eastshade! Unity very graciously invited us to show in their 3d Game Art Challenge, along with 11 other spectacular 3d games.
We will be located in Unity’s 3d Game Art Challenge Lounge, which is a large space on the ground floor of Moscone West near to their main registration area (which has moved this year). The lounge is in the ‘common area’ and means its open to all passes. Ie you don’t need an All-Access pass to get to it. We’ll be there the entire week of GDC, from March 19th-23rd. If you’re attending GDC, don’t hesitate to come by and have a play and/or chat with us! If you’re press and would like to schedule an interview or meet-up, please contact charlie@playertwopr.com. We hope to see you there!
We now have a Steam store page! It would mean the world to us if you go wishlist and/or follow the game there! Plus then you won’t miss its release :). Another way to ensure you don’t miss release is to sign up for our email notification list, so you get an email when the game comes out (we won’t send you anything else, just a release notification). With the release of our steam page comes an updated trailer, which you can watch on the store page, or embedded below. Since so much has changed since our initial announcement, I wanted the trailer to reflect all our updates. We now have full voice acting and lip sync after all! I’ve updated almost all the shots, and replaced some with new ones. Now that Jaclyn is helping me art the world, many areas have more tender loving detail.
In my last blog post Art Tips for Building Forests, I outlined some things I keep in mind when building the look of 3d forests. I stuck only to art tips, that is, tips for what assets you should have and things to think about when placing them. One of the most important things about a lush forest is density, and something that comes part and parcel with density is performance optimization.
Since there are many ways to tackle forest optimization, there aren’t many universal guidelines for how to author your assets. However, one thing that is universal (almost anyway) with regards to forest optimization is that your number one enemy will be draw calls (or in Unity known as batches).
While poly count is also important, the problem is not as complex. One just needs to know the reasonable targets. Here are some polycounts for a few of my assets for reference on what might be reasonable for a given type of vegetation. If you find yourself needing too many alpha cards to reach your desired canopy fullness, you may look into increasing leaf coverage in the texture.
Finally, there is overdraw. This is when you have lots of overlap between alpha cards and objects. I don’t even think about this or look at this, because frankly I don’t know what I can do about it. I’m not going to modify the silhouette of my trees to reduce overlapping. In fact, I’m not going to modify the silhouette of my trees for any reason other than to make them look as good as possible artistically. I’m also not going to modify the layout of my forest to prevent overlapping vegetation. It’s hard enough to make a forests believable without worrying about overdraw. I just concentrate on keeping down poly counts and draw calls.
If you came to this article hoping to find hidden Unity settings you can tune to make things more “optimized” I am sorry but I don’t have any of those. To tackle this problem you do need a plan. Most plans will require your forest to be built from the ground up with your optimization strategy in mind. If your forest is a smorgasbord of assets from disparate sources, you may have a hard time with this. As I said, there are many different strategies to reduce draw calls. In this article, I will attempt to show you mine. My goal, in a sentence, was to combine the LOD1 meshes (second LOD stage) into mega meshes so draw calls consolidate as the player moves further.
Step one in my plan was getting every gosh darn thing in the forest (or as close as possible) to use a single material. That’s right. All my forest assets share a single material. To that end I needed all my veggies to sample a single texture.
The reason I needed to do this was so I could safely assume any cluster of foliage assets could consolidate to a single draw call when combined. Had each tree or grass clump a unique material, the resulting combined mesh might have many submeshes, and therefore many draw calls. Authoring all assets to a single texture wasn’t difficult since I planned it from the start. I designated a 2048×2048 and allotted areas on the sheet for assets I knew I’d need, and then when I authored them I simply kept adding to the texture. It’s possible to automate this process. It would require modifying the UVs of all your foliage assets through script though, and sometimes you can organize things more efficiently if you do it by hand.
The eventual goal is combining, but first we need to determine how we’re going to combine things. It is unwise to make one giant super mesh, for two reasons: The first is that unity uses a 16 bit index buffer for its meshes meaning each mesh can only have 64k verts max (however it sounds like 2017.3 will use 32 bit index buffers, therefore this will be a moot point soon). Secondly, and most importantly, you won’t have a means of LODing individual groups or of taking advantage of frustum or occlusion culling, since your entire forest will be one mesh. The draw calls will be nice and low, but the triangle count might will be absurd. We can afford a few extra draw calls to save a boatload of triangles.
Enter the hex grid. Basically I wrote a script that automatically groups all my veggies into a hex grid. I chose hexes over squares since hexes are more circular, making a simple per-group position check for player distance more accurate. A square will have corners that may be sticking out closer to the player.
You will see later that having everything grouped into a grid is helpful for a few other optimization tricks beyond just combining.
With me so far? Here is one more layer to the madness. The hex groups are then grouped into super hexes. When every regular hex in a given super hex is at its LOD2 state (the furthest LOD which for me is basically two planes, sometimes referred to as an ‘imposter’ mesh), the super hex switches to a combined version of the LOD2 hexes, further consolidating draw calls. If you’re wondering why I didn’t simply make my first hex grid have larger hexes, the reason is that having smaller hexes allows me to capitalize on more granular transitioning to the far LODs, and more accurate culling (as mentioned in the opening paragraph of this section). When things are far enough and low poly enough they can be combined to larger hexes (this transition is unnoticable since by this point all the small hexes are already at their furthest LOD. We’re just switching to a big combined version of them).
Initially when I began to build my system, I combined the LOD0s as well as the LOD1s. I have found this to be too memory heavy. It makes every vertex on the highest poly version of all your foliage assets have a unique memory footprint, since every combined mesh is a unique mesh. Additionally, the larger your meshes are the less granular frustum culling is, thereby drawing more triangles than necessary. You tend to be standing close to or right on top of the LOD0 hexes, so the issue of inaccurate frustum culling is exacerbated. I found combining only the LOD1s to be the perfect balance. The LOD1 is low poly enough to use very little memory, but has the most massive savings since most of my loaded world will be in a LOD1 state.
Unfortunately combining meshes in Unity is not straightforward. I had to write my own script, since the scripts I tried on the asset store don’t handle submeshes or vertex colors. As far as how you structure the data for your LODs, that is up to you. I opted to not use the built-in LOD component, since it would merely be a data container anyway (the hex groups handle the LOD switching). I simply use a monobehaviour with references to deactivated child GameObjects, so I can easily get the materials and submeshes from their renderers.
Here’s an important thing to know: the built-in Unity LOD component is expensive. Especially if you have one active on every clump of grass. That is a lot of distance checks happening on the CPU. One of the wonderful benefits of having your world divided into tidy hex groups, is that you can distance check on each group, instead of each child object. Then the entire group LODs as one unit. I even have an animated transition that uses the alpha cutoff property in the shader (a simple way to get a nice blend!)
Another use for the groups is a sort of dynamic occlusion culling. I do not use Unity’s built-in occlusion culling, because last time I checked, it does not mix gracefully with multi-scene. The groups are few enough to where a few raycasts during runtime can be done to see if a hex is entirely occluded from view. I do not do these raycasts every frame, I just give enough extra leeway in the hex bounds to make sure things appear in time when going over hills and around corners. You could never do this for every object. It would be way too expensive. But a few raycasts for a group of 20-50 objects will be worth it, especially when it is only happening every few frames. I only check for occlusion against terrain, since nothing else in a forest is substantial enough to reliably occlude.
A smooth LOD0 to LOD1 transition is usually better than a low polycount on the LOD0. If your transition is nice you can move the LOD distance closer, thereby reducing total polys on-screen. One thing I do particularly for my trees, is author with the LOD1 in mind. I build my trees from branch instances in my 3d package. This allows me to author a LOD model for a few single branches, and then update all the instances with this lower poly version to create my complete LOD1.
Terrain (by terrain I mean the ground itself) is a little outside the scope of this article, but I feel it’s important to note that I don’t use the built-in Unity terrain system. Therefore all my veggies are regular GameObjects. I opted to use regular meshes over the terrain system for three reasons: The first is that the default Unity terrain system is very poor on performance for the blobby mesh it gives you, and creates hundreds of extra draw calls and thousands of poorly distributed polygons I can’t afford to waste. Using a regular mesh allows for controlled distribution of polygon resolution where you need it. Secondly, authoring shaders for the default terrain system is very restrictive, and there are a lot of idiosyncrasies about it which are poorly documented. Lastly, I have plenty of holes and overhangs. The shader I use for my ground is fairly straightforward. It’s a three channel vertex splat with a macro overlay and normals.
It’s important that your vegetation shader general performance (known as pixel fillrate) is reasonably optimized. If you are using a deferred rendering path, getting your vegetation shader to be fully deferred can offer huge savings. Mine used to be forward rendered, and when I finally figured out how to get the same shader deferred, I shaved 30% off my render time. Creating a fully deferred vegetation shader with the required translucency was not at all straightforward, as you need access to the light attenuation, which can’t normally be accessed in a deferred shader program. I realize this next part is getting far into the weeds of Unity specifics, but to any curious, I use a surface shader with a custom lighting model that writes a very low fidelity translucency mask into the unused 2 bits in the G-buffer (the alpha of RT2). Then I added the translucency function to Internal-DeferredShading.shader. It took me years before I finally figured out how to do this. Here is the thread where a kind soul eventually helped me figure it out. It was so brutally difficult for me to figure out (took two years) that I’d gladly help anyone with this if they reach out.
Baking lighting for all the plants in a forest results in massive lightmap memory usage, production unfriendly bake times, and I found it to not look that great anyway, since alpha cards don’t generally make nice bakes. I use light probes for anything smaller than a building. I use Light Probe Proxy Volumes for the trees, so there is a nice gradient to lighter values in the canopies. Since the trees are not static, and aren’t seen by the light mapper, I needed a way to darken the probes of shrouded areas manually. I wrote a simple script that tints all the probes within a given volume by a color of my choosing.
Unity introduced GPU instancing in 5.4. To use it you must draw the mesh from script. Its different than combining meshes, and in some respects it’s better since you can draw many meshes in a single draw call, but don’t pay the memory overhead associated with uniquely combined meshes. There are, however, a few disadvantages. Since you need to draw the meshes from script, if you want to do any culling of any kind, you need to maintain a list of which meshes should be visible. Beyond the simple fact that you have to write all this yourself, keeping this list maintained in C# can be expensive. Furthermore, passing this massive list (or multiple lists) to the GPU is expensive too.
I have tested GPU instancing fairly extensively. I even replaced my entire grouping system with a GPU instancing system. I found that it was not as performant as my combining system, and had more limitations (such as not being able to use light probes, or Light Probe Proxy Volumes, which are essential for my forest lighting).
There is a new method introduced more recently, called DrawMeshInstanceIndirect, wherein you can use a compute buffer to make the maintaining of your instance lists more performant. It is possible this is an even better solution than my combining system, however there isn’t much documentation on it, and I am not a good enough programmer to figure out how to do it. I tried. I failed.
The TLDR for performance optimization in lush forests:
And that’s about it! My current combining system (I call it the hex grid) is my 3rd iteration of combining system, so these are the things that ended up working for me after a bit of trial and error. I use it for many of the objects in my world, not just foliage. It works well whenever there are a lot of objects of one kind (like barrels or rocks, for instance). At best multiple instances of an object will consolidate to a single draw call, and at worst there will be the same amount of draw calls as there were before, but with higher memory overhead. Please don’t hesitate to reach out if you have questions.
For the past nearly four years of Eastshade development now, I’ve been pretty dogged in my belief that Eastshade should be text-only dialog, like Final Fantasy. I held this belief due to the following reasons:
These are reasonable points in favor of no voice. However, things have changed, I’ve done more research, and my outlook has changed. The first critical thing that changed is I got rid of the mouth coverings in the character designs from Leaving Lyndow. I initially thought that mouth coverings would be a design decision that would make things easier, weather we did full voice or greeting lines only. However I learned the hard way what a terrible mistake this was. The difficulties of art design with mouthless characters turned out to be far greater than any savings in production. Of the criticism we received for Leaving Lyndow, the facial design of the characters was probably second most common.
New and improved!
Once the characters had mouths, I got to thinking: What other bad decisions have I made in the interest of saving production time? I questioned everything about the characters. How hard actually was lip sync? Was I blowing it out of proportion? I’d never actually tried, so I carved out a day, and told myself “If I can get a reasonable dynamic lip sync on a character in a work day, then full voice might be viable.” Well turns out lip sync was easier than I’d thought. With the help of a Unity plugin called Salsa, I smashed the goal with flying colors. The assumption I’d been holding for nearly four years was turned upside down in a single work day!
And moreover, I made another assumption-shattering discovery in the experiment: Even with extremely amateur voice acting recorded by yours truly, the character came to life before my eyes. As I imagined each character with their own unique voice, I could feel another dimension of discovery materialize. Each character would have a new type of feedback to offer, and despite how much repeat there was in the character models, distinct voices would bring another layer of spice.
Once I knew it would be technically feasible, and I realized that I didn’t necessarily need Meryl Streep, the last thing in my way was costs and management. After doing some research around the web, its clear now that costs aren’t as inhibiting as I’d assumed. And for how much value I can see it adds, I know it will be worth it. The last thing that remains to be seen is weather we can handle casting in an organized enough way, and empower each actor to create their own deliverables that we don’t have to do a ton of work making game-ready.
So without further ado, if you’re an interested voice actor with means to record yourself, here are our open audition guidelines!
Leaving Lyndow is a short (about 45 minutes) first-person adventure game. The game is a prequel to our upcoming open-world game Eastshade. While set in the same setting as the larger upcoming title, it features distinct mechanics and story. We announced Leaving Lyndow on January 11th, 2017, less than a month prior to its release (official trailer). To avoid confusion with Eastshade, currently still in development, we released a short video explaining the reasoning and history behind the small titles’ odd format and development. As outlined in the video, our reasons for creating such an odd and small game were three-fold:
So the title seemed like a good idea from both a business perspective and an artistic one. The idea for Leaving Lyndow came to me after playing a short experimental game called Home is Where One Starts by David Whele. I enjoyed the 30 minute vignette of a title, and found its brevity refreshing compared to the much larger time commitment of other games. As a consumer, I feel there is a lack of games in this format, and I found myself inspired to make my own. Apparently many in the general gaming public are not as enchanted by short games as I am. More on that later.
Leaving Lyndow released to mostly positive reviews, scoring a 74 on metacritic (sadly one point below a green 75), and 84% positive steam reviews at the moment. Between myself full-time and a few part-time contractors, development took over six months, which was about double the time we planned for it. I’d like to reflect on the debacle as a whole. There are two perspectives in this postmortem: Reflecting on the development process, and reflecting on the business strategy and launch. Since I’m a near one-person show, these undertakings are blurred together for me, so I am going to mash them both into this one article.
First and foremost, did this thing work? Did it better prepare us for Eastshade’s launch? Was it an effective fundraiser? Additionally, was it effective at building brand?
At this point I’m entirely certain that had we gone on to release Eastshade as our first title instead of this small thing, it would have been a major disaster. Between localization, learning the Steam back end, finalizing all the pieces, running a closed beta, I can only imagine how much more difficult doing all that for the first time would have been with a game ten times as large and complicated. For example, shortly after launch I accidentally removed the soundtrack from the Steam depot, causing everyone’s soundtrack to vanish from their computer as Steam automatically updated the removed files. Even worse, after some reports, I discovered there was a bug in the localization system, where somehow it had generated a few duplicate string ids scattered throughout the games’ text. This resulted in some dialogues feeding you the wrong line. The only way to fix it was to go searching through the localization tables for duplicate ids, give the duplicates new ones manually, and hunt down which string was supposed to be in the corresponding text field. This was especially difficult when I don’t speak the language of the localization I’m fixing! Now what if that had happened with a localization table ten times as large? I’ve since pinpointed exactly how those texts got jumbled and now all that’s sorted for Eastshade. I’m glad I’ve learned the ropes of all this before launching our 4+ year development title.
As for fundraising, for what is now our first three months of sales, our revenue is about $10,000 USD across both itch.io and steam. That more than recoups what I paid out to contractors, and now every unit sold is slowly paying me back for my own time spent. I expect this figure to continue to rise throughout the year, and we are currently working to bring Leaving Lyndow to consoles. So I don’t expect it to expand Eastshade‘s production budget substantially, but over time, I think it will eventually pay for itself handily.
I believe Leaving Lyndow has been an effective marketing tool for Eastshade. Press are far more likely to cover a release than they are to cover a crowdfunding campaign, so the visibility we’ve gained form this release has been substantial. Moreover, thousands of people have gotten a taste for the Eastshade world now, and as far as I can tell they are hungry for more.
This review is telling, even despite its misinformation (Eastshade is not the full version of Leaving Lyndow. They are two mechanically distinct games). They felt the game was too short, gave it a thumbs down, but despite this they are still interested in our next game! Hooray!
As the Leaving Lyndow project was first and foremost an exercise in releasing a game, I knew it would be an excellent opportunity to try working with a PR company. This project would be small enough that if it wasn’t a good fit, the damage wouldn’t be too great. When choosing a PR firm, I think a size match is important. Granted, its not like I’ve done a lot of business with tons of PR firms, so know that this is a bit of arm chair speculation on my part. But it seems to me that if you’re small, and you get a medium or large firm, your launch campaign likely won’t matter much to them. Not because they’re evil, but its just the dynamics of human psychology. You can’t possibly occupy much space in the firms’ organizational focus. Conversely, if you’re a big studio, you wouldn’t want to risk your launch campaign on a small firm that doesn’t have the bandwidth you need for your larger production.
I couldn’t have asked for a better fit than Player Two. @CharleneLebrune knows the games media landscape well and is current in the protocols and practices of games PR. With her help we managed as widespread coverage as we could have hoped for, being covered by the likes of Kotaku, Polygon, and PCGamer and many many more. I can’t tell you how relieving it was to know that the publicity front was being handled in those most stressful months leading up to release. I think it’d be completely insane to attempt doing all the press liaison, review code distribution, and inquiry responding on top of normal development crunch in the final month. Moreover, PR is its own skill, and to do it effectively takes study and practice like any discipline. If you’re indie like me you’re likely juggling enough disciplines as it is, and this discipline is easily outsourced. They don’t need to be trained in your tools or familiarized with your game architecture to be effective and save you tons of time, so I think it makes a lot of sense for an indie studio to contract a publicist.
As I’ve been working on a large game for the last 3.5 years, sometimes my brain tries to scheme a way out. “What if I just made a smaller game instead of this one!” And for a minute I fool myself that if I could only start fresh with something “smaller” things would be easy. But, alas, this is usually not the case. Every game seems smaller than the one you’re working on. Only when you delve into the depths of production do the complications in your designs show themselves, and once more you are reminded that the pan is hot. But this time the smaller idea I had seemed so assuredly small, and my inspiration burned so hot that I couldn’t help but succumb. Cautious as I am of the wicked allure of a smaller game, I told myself I had one night to produce a prototype. If I didn’t have a skeleton prototype that could be played start to finish by morning, I’d end it right away. By 6 am I’d accomplished just that. And rather handily! I knew it could be done. And once I’d discussed it with my co-designer girlfriend, we verified the sanity of the idea from a business perspective. Even with all this sanity checking, my scheduling was off by double.
It was tempting to create a new Unity project directory and code Leaving Lyndow from scratch, but I decided to branch the Eastshade build and commandeer the game logic. Its easy to forget how time consuming simple things like pause menus can be, and it was nice to have scaffolding to work from. The added benefit to this was that I was able to polish things like the options menu, and easily take those improvement back into Eastshade. I’m not an accomplished programmer, but I already find myself having those all-too-programmer temptations to create things anew, ensuring elegance and bloat-freeness. While a noble sentiment, I have found this persistent desire to remake and refactor to be dangerous. I have no doubt it is the surefire way to become a better programmer, but I also have no doubt it is the surefire way to never finish games. Sometimes one has to decide: Do you want to become a better programmer and be totally satisfied with your architecture? Or do you want to finish the darn game? The very essence of Leaving Lyndow’s development was the later.
During the development of Leaving Lyndow, I spent a great deal of time on optimization. In fact, There was one shader I spent almost two weeks optimizing alone! It was one of the most prevalent shaders in the game (the vegetation shader), and ended up increasing frame rate by about 30% across the board. I’m very glad I did this. I think a smooth frame rate is something players appreciate a lot, and I’m convinced it tremendously improves the perceived production value of your game. Often the first criticism of a bad game is its poor performance. All this groundwork in optimization will carry through to our future games.
From a developers perspective, I feel game length is a bit of a paradox. The harder you work to hone the experience, cutting the weak parts, streamlining the tedious actions, the shorter the game becomes, yet the better what’s left of it is, and consequently the greater the loss is felt for lack of content.
Leaving Lyndow, for its shortness, is fairly dense. Much to the sorrow of many players, your avatar cannot run. Yet despite your movement being slow, the game’s pace doesn’t feel slow, because within under an hour, you experience six entirely distinct environments, and five unique music tracks. Compare this to other adventure games, where you might see the same number of environments and hear the same number of songs but over the span of six hours. I believe its this density of audio visual content that makes each moment you spend in Leaving Lyndow exciting, but its exactly this density that collapsed the game into such a short play-time. “I liked it! Why didn’t you just make more?” the gamer says. “There was more,” responds the developer “but I trimmed it down so that you would like it.”
It is said that “too short” is the best criticism you can have, but in Leaving Lyndow’s case, given the ubiquity of the criticism, I think it may indeed have actually been too short. I think there’s a reason people don’t make short games. I don’t know if the market’s bias against short titles is self-perpetuating, and we are working against arbitrary length standards, or if we’re rather working against ones inherent in the medium, but one has to deal with the perception no matter the cause. If I could do it all over, I’d have made the game longer. In addition to adding more content, I would have worked a bit to maximize length with the content we had. I think the content we had could have sustained interest for longer than I’d thought. Moreover, there is a certain startup cost to create a new design, and once you get things working, additional content is a bit cheaper. We could have increased the price to compensate, given that most agreed the price was fair for the time they got. They just wanted more time.
Given the low price point of $3.99 USD I decided to release without a launch discount. I thought discounting such a low price was unnecessary. After all, 20% off would have only been 80 cents less! In hindsight, I have a feeling this was a mistake. I can never know for sure how much damage it did, but I suspect we would have more than sold enough extra copies to compensate, and more importantly, we would have had a better chance of holding in the “popular new releases” list.
This is all speculation, since Valve’s discovery algorithms are a guarded secret, but myself and a few of my fellow developers feel that staying in the popular new releases list is very important not just for launch performance, but for the long term revenue of your game. Leaving Lyndow seemed to be just on the threshold of selling enough, because we kept popping in and out of that list for the first two days of launch. Despite the fact that the list primarily brings traffic during the first week, to this day (3 months after launch), our placement in that list is responsible for a whopping 2.3 million impressions, and 20% of our total page visits. I can imagine if we held firmly in that list instead of popping in and out, we may have sold twice as many copies at launch, potentially improving our standing in Steam’s algorithms forevermore. Given the average steam user’s trepidation to ever purchase anything full price, I think that little green discount swatch in the corner of our thumbnail would have improved our conversion just enough to make all the difference. I need to say it again, this is all my personal speculation, so take it with a pinch of salt, but you can bet your boots our next release Eastshade will have a launch discount.
I don’t think this was so much a mistake we could have corrected, but rather an inevitable consequence of doing something as bizarre as we did. Leaving Lyndow is a short game that looks similar to Eastshade at first glance, is set in the same world, is only 45 minutes long, yet its totally self-enclosed, is not a demo, costs money, and has nothing to do with Eastshade mechanically. From a branding perspective, does it get more confusing than that? We knew this would confuse people, so we went through great lengths to make things clear in every press release. That’s also why we went through the effort of making that talking head explanation. I clarified often on twitter as well. Yet many still mistook Leaving Lyndow for a demo. Fortunately most reviewers conceded it was nonetheless decent value given its polished content and low price point. But there were a few who had it in their head that short things are demos, and demos are supposed to be free. This was mildly frustrating, but all in all the vast majority of people didn’t complain, enjoyed their experience, and were excited about our next title. So I think the confusion was a small price to pay, but I feel this point deserved mentioning for those of you who might be considering unconventional business plans.
The most devastating mistake I made was the design of the character faces. I had in mind to do them part monkey, part human, and devised the cultural quirk that they cover their mouths (largely to avoid lip syncing the jibberish greeting lines each character dispenses when you speak to them). I have no problem with them looking hideous. I think we as a species would likely be better off if we minded looks less. My issue with them is that for all their hideousness, the design isn’t creative, clever, or even iconic. Its bland and hideous at the same time. We likely would have done better to go full anthropomorphic, and put any other animal head on (an animal that isn’t already so darn close to human anatomy).
To make matters worse, the jaw line and mouth is an extremely important feature in facial recognition, and it became even harder to create distinct appearances for the characters. I assure you the challenge of face design without a mouth is more expensive and arduous than lip sync. This shortcut turned out to be not a shortcut at all. Combine this with the fact that almost everyone is bald, and you have a recipe for bland characters that all look the same. I’m working with an amazingly talented character modeller, but I handled the face designs myself, and character design is something I’m rather bad at. I should have found someone else to do it.
I’ve worked myself into a bit of a bind here with our island of ugly characters. I have decided I’m going to rip the band aid off right now, and we’ll be adding new character types for Eastshade. The monkey folk may remain, but they will only be a percentage of the population, so at least we have some variety and interest. It might be a bit strange lore-wise for all these new races to arrive suddenly for Eastshade, but I hope it can be forgiven for the sake of future world-building.
While we will never again make a game this short, we accomplished many goals with the Leaving Lyndow project. Most importantly, it vastly reduced the chances of our next big release becoming a spectacular train wreck. Some of the development work we did will carry through, and our code is somewhat more battle-tested now. Our brand got some attention, and thousands now await what we do next. I learned how to use the Steam back end, and got a little better at talking about our games. We’re well on our way to breaking even on the production costs, including my own time, and I’m hopeful the long tail and console release will help fund future development. Hopefully another thing we learn from this is how to port and certify a game for console, which still lies before us. One last thing I personally got out of Leaving Lyndow is the confidence to know this indie thing can work. All these years I’ve felt very uneasy about the future. I still feel uneasy, as it comes with the territory when you are running your own business, but not as much as I felt before, and its nice to know that when we ship a game, money does indeed come into the bank account.
