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.
LODing and Culling using the Hex Groups
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.
Authoring for Smooth LOD Transitions
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.
- LOD1 half way up a tree – Some trees are tall enough that you can get away with the upper canopy being lower poly. This is where my packing all LOD stages into the same atlas and material is handy. It enables me to do this without adding extra materials to the LOD0.
- Dead trees, or trunks without canopies – I tend to reach my desired canopy density long before I reach my desired trunk density, so adding trunks without canopies is a thrifty way to make a forest look thicker.
- Mega patch assets – In flatter areas of your map, you can make large patches of grass as a single object, thereby reducing draw calls even when things are in the LOD0/uncombined state. Every one of my grass and undergrowth assets has a large patch version.
A Note About GPU Instancing
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:
- Draw calls will likely be your biggest problem. You need a plan to keep them reduced.
- Poly count is an easier problem, just make sure the triangle count of each asset is reasonable.
- I ignore overdraw considerations because there’s nothing I can do without ruining the look.
- All my foliage textures are atlased to one material, to ensure combined meshes become a single draw call.
- I use a grouping system that combines the LOD1s of all the meshes in a group.
- I don’t combine LOD0s because it uses too much memory as the meshes are higher poly.
- The groups can’t be too big, because then you can’t take advantage of frustum or occlusion culling.
- I use my own LODing script since I do LOD switching by group rather than by object.
- I use my own mesh combine script, to gracefully handle vertex color and submeshes.
- I author my foliage assets by hand, often with a plan for the LOD1 in mind.
- You can animate alpha cutoff to make a smoother transition.
- I use regular meshes rather than Unity’s built-in terrain system.
- I wrote a fully deferred vegetation shader to keep pixel fillrate down.
- Baking lighting for foliage was not feasible for me, I use light probes to light my forests, with a custom tinter volume for shrouded areas.
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:
- Voice acting means we have to do lip sync animation.
- Lip sync means tongue model, teeth model, full facial rigging, and full phoneme markup for every gosh darn character.
- The costs of casting and recording full voice for Eastshade’s 20,000+ words over more than 40 different characters.
- The overhead of managing many different voice actors and deliverables.
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.
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:
- As an inexperienced studio, we wanted experience shipping a title before shipping our much larger and more costly-to-develop title Eastshade.
- We wanted some supplemental funding, and suspected a small game would be equivalent work and more effective at fundraising than a crowdfunding campaign. More on that later.
- We like short format games, and were deeply excited to make this one.
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.
What Went Right
Small Game Instead of Crowdfunding
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!
Hiring PR Help
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.
A Rapid Prototype
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.
Using Eastshade’s Build
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.
Spending Extra Time on Optimization
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.
What Went Wrong
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.
Not Launching With a Discount
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.
Confusing Customers and Press
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.
Character Face Designs
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.
- Released February 8th, 2017
- 45 minute play time
- $3.99 list price
- 1 developer full-time, 4 contractors part-time
- six month development time
- Revenue for first 3 months on PC: $10,000 USD
- Game engine: Unity
As an environment artist in the games industry, I’ve made quite a few forests over the years. At Eastshade Studios, both our recently released title Leaving Lyndow, and our upcoming title Eastshade feature plenty of forests. There’s something very powerful about walking through a shroud of trees, and attempting to recreate that feeling in a game world is one of my favorite things to do. In my unending quest for pretty forests, I’ve learned a few things that I believe are important to eliciting that growthy feel. Some may seem simple, but I’m always surprised by how many game forests overlook some of these.
A disclaimer: This article is not about how to create great foliage assets. There are quite a lot of good resources on that topic. This is also not a technical tutorial on how to author a forest in terms of shaders, lods, or optimizations. I actually have a lot to say on that topic and would like to write another article at some point on that specifically. This article focuses on the larger picture such as deciding what assets you need to make, how best to use them, things to think about, and ideas for more believable and less monotonous forests.
I’ve heard this a thousand times, maybe you’ve heard it a thousand times, I’ve said it a thousand times, and nonetheless, I will say it again: Reference is paramount. Virtually all the things mentioned here I learned as a result of looking closely at reality, and making decisions about what is important to the big read. Walk in forests, pay attention, look at what’s there. Rely on what you objectively see, not your own ideas of what a forest has. Whenever you are trying to capture the magic of reality, you need to be informed by what you actually see, not what you think you see. This is true even if your forest is a stylized fantasy forest with orange waterfalls and blue bushes. With that being said, let me pass on some things I’ve found to be important.
Resist the urge to scatter foliage and trees evenly over a space. Organic randomness is a funny thing, so don’t be afraid to boldly cluster a lot of things together while leaving other parts practically barren. On top of this, a lot of small shrubs and sapling tend to grow symbiotically at the base of other plants. In addition to looking natural, it can also cover ugly intersections between your trunks and the ground. Sometimes there is a tightly packed cluster of thin trunks that almost seem to grow out of each other. Don’t miss things like this! Sometimes I see people spending hours toiling away at leaf normal maps while overlooking more noticeable things like tree placement.
This may be the most important tip in this write-up. Walk in a forest, and you will notice there are a LOT of trees. Hundreds of trees are in view at any given moment.
While mastering this level of density may seem like more of a task in optimization than a task in art, there is actually one crucial art trick that helps performance as much as any draw call batching, shader optimization, or GPU instancing, and here it is: Not all of your trees need canopies. Getting a tree to look right standing by its lonesome requires a lot of triangles in the canopy, and this is the way we author most trees. But when many trees are clustered together, the canopy reaches maximum fullness rather quickly, and any additional trees are adding thousands of triangles, but not helping fill the canopy. Put another way, we tend to reach our desired canopy density long before we reach our desired trunk density. So what can you do? Add trunks without canopies. In my case, I just use my dead tree models, which are much lower poly since they have no leaves.
Something I see commonly neglected in game forests are dead things of all kinds. A large percentage of the trees in a forest are dead with no leaves. This is true for both deciduous and coniferous forests. On top of adding believability, they also have the added benefit of being lower poly since they don’t have canopies (see the section on trunk density). When trees die, sometimes they fall. You can make an old overgrown log, or simply turn a tree sideways branches and all. Then there are stumps. Typically when one pictures a stump it’s the man-made stump, but there is also the broken off tree, or rotted out variety of stumps, which are natural and numerous in all forests.
Don’t forget unlikely notable sights, like a fallen tree leaning against another, a log dangling off a boulder, or a tree that has fallen into a river. Sometimes we neglect these things because we’re too focused on the more common sights, but these sights are often the most interesting in a real forest, why omit them from our fake forests? They are critical for breaking up the monotony of the environment.
Humans tend to look where we step, so players will spend most of their screen time with their camera pointed eye level or even cast downward a little. This holds true in both first and third person. When we author a tree, we often focus on its canopy, likely because it’s the largest portion of the tree in terms of sheer size. While the canopy is important, especially the silhouette as its cast against sky, in denser forests the canopy tends to get swallowed up by other canopies, and the trunks at the eye level become even more important. Photogrammetry (or photo scanning) can help a ton with this, especially since the texture of a tree trunk and its organic shape make for perfect photogrammetry candidates. You may have to use a separate 1:1 texture for the lower part of the trunk, and find a way to switch to tiling texture as you move up the trunk. This can be handled with a blend shader, or with multiple meshes if you can find an undistracting place to put the seam. Another option is to devote more texel density to lower parts of the trunk in the UVs.
I must admit I haven’t put enough love into some of my own tree trunks where they meet the ground, but it’s something I will definitely pay more attention to for my tree assets in the future.
Generally every available space on a forest floor is covered with some kind of foliage. One’s immediate intuition might be to use grass, but tall green grass is not terribly common for a natural forest floor. It can definitely create a cool surreal look to use a sea of grass under tall trees, but just know that shrubs, ferns, and low lying leafy stuff is much more common.
Rocks of all sizes are important. Pebbles in spots without plants can add a lot more believability to the barren ground. More and more people are using dynamic tesselation and building the smaller rocks directly into the texture. This is a great option if you have the shaders to support this. Otherwise placing the pebbles as meshes works as well.
I prefer to model my mid-size rocks in clusters. This makes it possible to spend time assembling a really nice looking formation which you can propagate quickly. Rocks are probably one of the best use cases for photogrammetry I can think of. If you have means to do this, I’d recommend doing so. Contrary to what some may think, it won’t save you time. It will very likely be more difficult and take longer than modelling them yourself, but the results are worth it.
Rivers, Streams, Lakes, and Ponds
In real life, if you get to the end of a forest hike without seeing any water, it was probably a boring hike. Hiking trails are often carved because of water. Water is probably one of the first things you should be laying down while deciding on the layout of your forest. I tend to decide on lakes and rivers right at the start, and build my forests around them.
There’s no two ways about it. Rivers are hard. If you’re new to game art, you may assume there’s an industry standard way of making rivers that you’re not being let in on. There’s not. If you know the perfect way to do them please let me know. I’m just here to tell you that you’ve got to have them, else you are committing to a forest no one would want to hike in. When I’m first starting my forest layout, I often lay in the bodies of water first, and structure the entire biome around them. Something that helped the look of my rivers was to dress the edges of my rivers in lots of rocks.
Forests tend to be very visually busy environments. This onslaught of noise can often make for an image without easily perceivable depth. This is true for forest photography as well. Something that can help with this is particles, weather it be butterflies fluttering about, leaves falling, white fluff drifting in the air, or dusty specs. The parallax and movement helps with perceived depth.
There are a couple of rabbit holes in forest making that I feel can waste a lot of time for little benefit. Approach these tasks with caution so you don’t fall in.
Variants – When creating a new type of foliage, start with one variant. I’m serious. Don’t start plugging away at a second or third variant before you even test your plant in an actual forest. For one, you don’t even know if this new foliage will work, or what will make it look good. So don’t waste time making five variants from the get go, only to discover you’ve crafted them in a way that looks awful in the context of a forest. What’s even more important: See how few you can get away with first. Will anyone even notice all the extra variation? Is there something more important you should be spending time on that will offer variety in a more impactful way? I got really far with only four broadleaf variants (eight including dead versions).
Modelling For Texture Bakes – This is quickly becoming the de facto way to create foliage textures, and I do it too, but you have to be smart about it. Don’t waste time modelling the perfect leaf and making variants of it. I don’t think it’s an exaggeration to say foliage textures are 90% silhouette. Spend all your texture creation time iterating on the silhouette, not the normal maps, or making sure every twig lines up with every group of leaves. Step back. Look at the big read. To illustrate my point, take a look at the comparison image below. On the left are some trees with a beautiful diffuse and lovingly baked normals. On the right are the same trees with a pure green diffuse map and no normal map at all. All it has texture-wise is an alpha mask.
As you can see, it’s not a huge difference. Squint your eyes and you probably can’t even tell. The left does look a little better, but ultimately the silhouette carries the weight, and both renderings read similarly as a tree. General leaf size, branch structure, coverage, and scraggly twigs should be where you focus your efforts.
Be Bold with Experimentation
I think it’s important to be creative with your assets. Sometimes you can stumble on something interesting, even if it’s not what you intended. For example, I onced jammed the second LOD model of an oak tree into the ground and found its canopy made excellent bushes. It was already low poly since it was meant to be LOD1. I did some quick work making them into proper bushes, and now I use them even more than my original bushes, and it offers great variety to the mid-level shrubbery.
The TLDR is:
- Use reference. Do research on real forests.
- Don’t distribute plants and trees evenly. Make some clusters of tightly packed vegetation.
- In dense forests, not all the trunks need canopies. This maintains density while saving polygons.
- Don’t forget about dead trees, fallen logs, decaying stumps, and anomalies like a dead trees leaning against other trees.
- Put extra love near the base of the trunk, where players eyes will fall.
- Cover the ground with foliage. Ferns and shrubs are more common than grass.
- Use rocks of all sizes to break up the endless foliage.
- Water is usually the most interesting thing in a forest. The more lakes, ponds, and rivers the better.
- Particles like bugs, leaves, fluff, or dust can add depth.
- Don’t waste time on leaf noodling or excessive variants.
- Don’t be afraid to try using your assets in unexpected ways.
Hey everyone! Leaving Lyndow is out! Like, right now! You can go play it! After three years we finally have something you can play. It’s not Eastshade. It’s not a demo for Eastshade. It’s its own thing. But we’re deeply proud of it, and we hope you like it!
In September 2016, we chose to take a break from Eastshade development to make a small Eastshade spinoff called Leaving Lyndow. The reasons for this were threefold: Firstly, as an independent studio who has never shipped a game, we feel unprepared to manage the logistics of a large release like Eastshade. You only get to launch a title once, and we feel one misstep could compromise four years of perseverance. This small game gives us a chance to experience the process. Secondly, we want additional funding to supplement Eastshade’s development while still remaining independent. Finally, we feel Leaving Lyndow enriches the Eastshade universe, and is a great way to begin building out the world for people. We want to allow you all in to Eastshade’s world right now! So without further ado, we present the official trailer for Leaving Lyndow.
We realize releasing a small game right in the middle of development of a larger game isn’t conventional, so here’s a little further explanation.
And if you support us on greenlight we’d be extremely grateful!
The sky is an important character in Eastshade. In addition to taking up a large portion of the screen at any given moment, it also gives players the sense that the game world has its own beating heart. While I knew I wanted to make the sky spectacular and dynamic, I also didn’t want to spend tons of performance or development time on it. While something like dynamic volumetric clouds can look absolutely awesome and convincing, they are out of my comfort zone technically and are very expensive to render at high enough detail to look realistic. After all, Eastshade is not an airplane simulator! So I opted for a solution with simple parts that I could hone easily with my artist’s eye, rather than a more procedural approach.
The Day Cycle Manager
Firstly, I knew there were going to be a bunch of values to tweak for each distinct time of day, so I wanted one central place to save/load and tweak them all. Since the sky setup is made of quite a few parts and shaders, I was led to create what I call the “DayCycler” component, which looks like this:
This custom inspector may look formidable with its many fields and values, but it’s really just a bunch of references to material values, light values, and rotations pertinent to the global lighting. Inside this component is a simple update loop which interpolates between the most recent and incoming time of day presets. With this simple system, I can go through and tweak each distinct time of day like a painter, and all the in-between times are taken care of for me. No need to manage 20 different IPO curves. The times are 0-1 rather than 24:00 so don’t be confused by times like 0.175 (that would be something like 4:12 AM). There are a lot of things in the world that look at the time of day which are more local, such as a a hanging lantern, or chirping birds. Little lights and audio sources like these drift in and out of memory as the world streams around the player. Referencing and managing all these little things in this central controller would be quite cumbersome, so the second part of this system is this little component:
I attach this to any little light or audio source that is day/night dependent and it looks at the current time of day and decides what value it should be independent of the DayCycler. No need to micro manage values like these.
The “sky” is composed of a few different elements:
Fog – Starting with the closest and moving out, we have the all-important fog. I use the fantastic Fog Volume for this. The reason I love fog volume is because of its gorgeous and fairly cheap light in-scattering. If you’ve never heard of in-scattering, I suppose it can be described as the look of sunlight passing through fog. I’m not talking about god rays (though in real life I believe its caused by the same thing). It adds a lot of depth and a sense of light direction to the atmosphere.
Clouds – Call me old fashioned, but I like the look of photo clouds. The biggest issue with photo clouds is that it is difficult to make them dynamic. My strategy was simply to take photos on a day that the clouds didn’t have a strong sense of light direction, combined with touching up the parts that look too directional. Once I had my 360 degree cloud panorama, I made an alpha mask cutting out the blue parts because I wanted to encapsulate the clouds seperate from the atmosphere. I mapped my clouds to a dome that rotates slowly to give the impression that the clouds are moving along the horizon. This trick is stupid simple, and is ineffective for giving players the impression that clouds are passing over them, so if you want that you will have to combine this with other methods like overhead UV scrolling clouds or something like that. I actually haven’t gotten around to doing overhead clouds yet, but funnily enough players tend to rarely look directly up and haven’t noticed.
Atmosphere – I find a simple 2-value gradient shader on a dome mesh is sufficient for the atmosphere. The opacity and colors animate with the day cycle. I increase opacity near the horizon so it looks thicker, while the stars show through more when you look directly up.
Sun – There are two parts to my sun. I have a sun flare, and an actual sphere mesh with a highly emissive solid color. This way I get a nice bloom, even if the sun is only partially showing. This is particularly useful for me in Eastshade, as there are daily eclipses and I needed a way of showing the sun slowly hide or emerge from behind the moon. The sun’s directional light doesn’t actually move around in the sky, it just rotates. To keep the sphere lined up with the flare, I rotate the sphere around the player’s head, rather than around its own center.
Moon – I designed a custom shader for the moon. It’s anything but physically accurate. It expands the light angle a bit, and uses heavy fresnel to fake the bending of light around the atmosphere. I have a special light that shines on the moon alone to simulate the sun hitting it. Here’s a bit of Eastshade trivia regarding its moon:
The moon in Eastshade appears habitable, and since its about the same size as the planet you’re standing on, you orbit it as much as it orbits you! In other words, both planets are moons to one another. This means Eastshade’s moon remains in the same place in the sky all the time, which creates daily solar and lunar eclipses. At midday it blocks you from the sun, and at midnight you block it from the sun. Tidally locked, you orbit around each other in a double planet dance all the way around the sun. Is there another world of intelligent life just across the cosmic pond? The residents of Eastshade can’t know. All they can do is look up and wonder…
Space – The furthest background is the space dome. This dome has a tiling star texture, supplemented with bits of geometry for the larger stars to break up the tiling. The reason I use geometry to break up tiling is because having a texture that wraps around the whole sky would require a MASSIVE texture to look sharp. The fact that stars are tiny little dots means they live or die on their sharpness. If I wanted to add a nebula or something like that I’d probably have that as a decal sticker on the star dome, because doesn’t tile and doesn’t need as much resolution as the stars. I’m trying to keep memory and build size down, mostly because I don’t want to waste development time maintaining a huge build.
Finally, its important to note that all these things follow the player around as they move. Since most of these things are supposed to look infinitely far, there shouldn’t be any parallax between the elements.
I’m not done with the sky systems in Eastshade. There are a few things left to do. Among them is come up with some sort of overhead cloud coverage to pass over the player. I’m thinking I will put a flat disc and use vertex color to taper the opacity around the edges. Then I’ll scroll the UVs over a tiling cloud texture. I also want to have multiple cloud textures for different weather conditions and fade between them. I’ll need to make a weather controller that operates on top of the DayCycler and plays off the base values, so I can have any weather condition at any time of day. I’ll need to implement a global wetness property in my shaders that increases gloss and spec, while darkening the diffuse a bit.
Last week we released our first official trailer and the response has been hugely positive! People seem genuinely interested in the game and it leaves us inspired as it does flattered. In addition to discussion on a multitude of forums, we received coverage from a number of news sites. While I can’t track them all at this point, I will attempt to gather them in this press roundup list for my own personal records, and for you all to check out if you want. I tried to include only unique articles, and exclude reblogs.
- Kotaku Australia
- Adventure Gamer
- A Handsome, Trustworthy Blog
- Future Beta Gamer
- Gaming Illuminaughty
- The Golden Cartridge
- Indie Game News
- Gamers FTW
- Gry Online (Polish)
- Adventure Zone (Polish)
- Babagra (Polish)
- Centrum Her (Slovak)
- Adventures Community (Bulgarian)
- Automation (Japanese)
- Games Tiscali (Czech)
- Loading (Swedish)
- Eurogamer (Swedish)
- Gaming Portugal (Portuguese)
- Video Gamer Portugal (Portuguese)
- Game Guru (Russian)
- Adventure Advocate (Greek)
- Metrotvnews (Indonesian)
After over two years of development, we’re proud to present our first trailer!
I want to clear the air about something. I’ve done a terrible job explaining what Eastshade is like to play. Part of that is because this project has been evolving over these two years, but the bigger reason is that my familiarity with the game makes me forget to talk about important points that nobody could possibly know. Jaclyn and I have concocted a concise explanation of what the game is:
“You are a traveling painter, exploring the island of Eastshade. Capture the world on canvas using your artist’s easel. Talk to the inhabitants to learn about their lives. Make friends and help those in need. Discover mysteries and uncover secrets about the land. Surmount natural impasses to reach forgotten places. Experience how your actions impact the world around you.”
Eastshade is a non-violent game; however, it’s not a game without mechanics, progression or goals. To me, a walking sim is a game that forgoes these things and focuses solely on atmosphere. Mechanically, Eastshade is a game that gives players the space to wander. We’ve made an effort to make the world feel alive and responsive as players explore. But there is also a clear sense of direction and progression. Here is a condensed description of the things you can do in Eastshade:
Meet the Inhabitants – Interact with the locals through dynamic conversations with discoverable topics and branching dialogue.
Capture Your Surroundings – Compose paintings anywhere in the world and offer them to characters to gain items, knowledge, and unlock secrets
Find and Craft – Acquire materials and schematics to surmount obstacles.
Interweaving Micro-Stories – Actions and dialogue decisions affect future interactions and outcomes as you meet new characters.
Story wise, Eastshade is not one particular tale that we were burning to tell. In order to allow the player to live the experiences we let go of orchestrating a controlled storyline and focused on building the world at large. To that end, Eastshade is filled with many little stories; each with their own effects and consequences on the state of the world. If you love the distilled sense of place that some walking sims have, Eastshade has it for you. However, if you weren’t a fan of Dear Esther or Gone Home, it doesn’t necessarily mean you will dislike Eastshade.
Hopefully that clears things up a bit, and hopefully the new landing page does a better job of giving newcomers the gist of what the game actually is.
We haven’t talked about it much in previous blog posts, but you play as an artist who can paint anything you see. Painting is core to the game. Inhabitants will commission paintings of certain objects, locations, at certain times, or weather conditions. Some puzzles are solved by making paintings with particular compositions. Painting in the game is kind of like taking a photo. Its a mechanic that rewards players for paying attention to the world they’re in.
The vertical slice, effectively a third of the game’s total content, is now at a point where it can be completed without console cheats (most of the time). Some testers have managed to finish everything there is to do (so far), without needing any direction or explanation. There is a game here, and it reportedly doesn’t suck. This is a joyous and momentous milestone!
There are still some placeholder assets and usability things to iterate on, and it will inevitably regress as we continue to make game-wide changes, but at this point the vertical slice is beta level, and we are ready to move on to the broader world of Eastshade! The great part about having polished one section is that we’ve worked out the design and built the framework which will carry us throughout the rest of development. As we were careful not to tangle ourselves in a tapestry of story dependencies, we will have a lot of freedom moving forward. Fresh starts are exciting! Especially when you feel you can attack with a honed strategy.
Unity 5.3’s new multi-scene features could not have come at a more perfect time. Everything now streams in as you walk around. There is only one quick loading screen when you start the game, and from there the world is completely seamless. The player can walk into new areas, caves, cities, and interiors without a hitch. Its also much easier to work in the world from an authorship side, because you can unload things you don’t need to see at the moment, and the editor stays light.
Content development is moving faster than ever at the moment. We have specialized and mature tools for authoring conversations and quests. We’ve settled on the game’s systems; they are implemented and working and we won’t add more. We’ve cut things that didn’t work, and revamped things that had potential. We’ve refitted content multiple times as we struggled to find the game’s center. The volatility is settling down now. All of the rest of the game’s content will manifest through the verbs we’ve established, enabling efficiency and better quest design. I’m excited to finally capitalize on the foundation we’ve been building for two years!
As we’re developing the game, having others playtest is invaluable and essential. We can hypothesize about how the flow of the game will go, but hypothesize is all we can do until someone else has played it. For Eastshade, there is one type of playtest that is particularly important: Not a speed run from myself or Jaclyn (who helps me with writing and design), not a thorough test for bugs or performance hot spots, but a tissue test! (I think kleenex test is the common way of saying it but I like the double T.) A tissue test is where you watch someone who has never played the game before, play without explaining anything or guiding them along. The more unfamiliar they are with your game and the less you speak while they play it, the better. They call it a tissue test because a someone can only be a first-time player once. As creators, we’re unable to see the game from fresh eyes; we know the hooks for every quest; we know where to find every item and we know every nuance of navigating the menus. Only from a tissue test can we can see if the UI is intuitive, or if a certain quest goal isn’t being communicated clearly enough.
Every few months, I’ve been trying to schedule a play test with a one or two folks who are unfamiliar with the game. As I’ve said before, I’m trying to be frugal with the amount of fresh eyes I use up, and I usually get so much feedback from just a few tissue tests that it keeps me busy for a month or more. Just recently, a test session took place (long over due!), and I’m happy to report it went astoundingly well! The content took longer to complete than anticipated, which is a good thing (as long as it wasn’t because something was unintentionally tedious or frustrating). The successful impact of certain quest moments filled my heart as a designer.
Despite these hopeful tidings, we still have mountains of work to do. We found we needed more gameplay “breadcrumbs” all around, to lead the player on the interesting paths. In fact, I’ve found there can never be too many breadcrumbs! As long as the hints are diegetic (in the actual game world rather than in a UI or something) and don’t spell things out too much so as to spoil the player’s sense of discovery, adding more breadcrumbs decreases the chances of the player getting lost or stuck.
In addition to the in-person play tests, I’ve attempted to give the build to some friends to test remotely, and I learned a valuable lesson from this: At this point in development, remote testing is far less fruitful than on-site testing! Without being able to see exactly how certain moments go down, I’m completely in the dark as to how to interpret feedback. In addition, the game has to be really polished for this kind of testing to be of any use at all. Little bugs or unfinished things can be devastating when the player has no idea what went wrong and I can’t be there to set things right with a console cheat.
Some days I look at the work left to do on this game and think “Who am I kidding? I’m in way over my head!” And other days anything seems possible. I find it hard to put a percentage on how complete the game is because of the volatile nature of production. The portion of the game currently being worked on is about a third of the total planned content, and this portion feels close to being done. Once this part is A-Z, the next section of the world will be kind of like Eastshade 2, because we can use the experience gained so far to go back to the drawing board with designing new content. So, onward we go!
There was once a time where I was unsure of whether Eastshade would feature non-player characters. My initial plan was to make the game as if there weren’t going to be, and then add them if I had time/money left over. After much head scratching, I started to feel like the design challenges of creating intrigue without characters loomed larger than the technical challenges of implementing these characters. I think we are inherently interested in our fellow humans, and while there is charm in desolate worlds such as Myst, I’m more excited by the prospect of an inhabited world. I can only prescribe narrative excuses for scattered notes and recorded messages so many times before the tactic wears thin.
At this point in development, characters are a pillar of Eastshade’s world design, and many points of interest in the world rely on them. I’m trying my hardest to make them feel like inhabitants, rather than info booths or quest pickup points. In my efforts, I’ve created a scheduling system so that they can be programmed to go about their daily business, and have conversations with one another as well as with the player.
With NPCs now a massive part of the game, there came the need for an elegant way to wire up conversations. I could immediately sense that scripting every conversation in C# would not do, so began my journey to find a solution. The first thing I tried was Unity’s Asset Store, as there are a number of dialogue suites for sale there. I’d settled on one for a while. The tool had some quirks that made things more difficult than they needed to be, but at the time I felt creating my own tool would be a net loss time-wise. After about 10 conversations, I grew to loathe the task. Because of how much I dreaded doing it, I found myself avoiding the creation of new conversations, opting to focus on anything else I could conjure up an excuse for. When I came to realize this, I made the decision to roll my own solution. I decided that even if it turned out to be a net time loss, net joy is also something worth considering in production.
I initially tried to make a sort of conversation markup language, where I defined each conversation stage with an ID and tags for the data. I opted to make something very specific for my needs rather than using XML. I’d write these text files, and I had a parsing function in C# that read all the strings from these text files and stored the data in a serializable class to be saved in the Unity prefab. Clearly this was an ingenious idea. Except that it wasn’t. Authoring these text files turned out to be even more nightmarish than the asset store tool I’d been using. It was impossible to keep a mental image of which choice went to which stage of the conversion.
So my first attempt turned out to be a failure, but not all was lost. I’d written a GUI Manager and data structure that worked very well, I just needed a different way to author the data. I now knew that I would need to take the more conventional route of a visual node based editor to wire up my conversations. I’d already lost days on my first failure, and was rabid to kick the problem in the face with vengeance. I thought hard about how I’d go about it. Writing a unity editor extension seemed sensible, but after some research, it seemed zooming (ABSOLUTE NECESSITY FOR A NODE EDITOR) was going to be tricky to implement. I contemplated writing a standalone app, but as a fairly green programmer, I’m not terribly familiar with any GUI libraries other than Unity’s. Then I had a crazy idea…
Of all the GUI libraries I’ve used, Unity’s new run-time UI (UnityEngine.UI) is the one I understand the best. With that one, I knew I could crank out a node editor with flying colors. I could even build the project as a game itself, and have myself a standalone app to work in. I would author my conversations in this game/app/tool monstrosity, and it would save out these text files in the markup I’d created. With my conversation assets being human readable text files, I could open them to make quick edits that didn’t require seeing the whole node tree. I could run any search and replace functions a text editor has at its disposal. So this turned out to be the winning solution.
With the conversation crafter “game” being a portable standalone app, as well as highly specialized for Eastshade’s needs, an understanding of unity scripting is no longer needed to implement conversations into the game. This has enabled my partner, Jaclyn, who is creative and like-minded, but isn’t a programmer, to contribute weird and interesting characters to the world! All in all, this detour took a week or so, which isn’t substantial considering how much more palatable this aspect of development is now. I no longer have the trepidation when I need a new conversation, and that has been well-worth the price.
The title of this post is a ridiculous question to me. At the very least it should be a ridiculous question to any game designer, but I also think it should be a ridiculous question to any gamer. It appears the latter is not the case, because its a question I’ve gotten more than a few times when I try to describe what this game is to people. I suppose it makes sense, because games wherein you control a single avatar tend to be about killing enemies in one way or another, and people may not have considered how very specific that paradigm is.
I’m not saying there isn’t innovation left to be done inside that box, or that I think people should stop making these kinds of games. Combat is human, and its an engaging subject to make games about. But there are other aspects to humanity that we can explore through games. I have nothing against dude-killing games, but I do think its odd how many game designers seem to only think inside of that particular box. There are certainly many genres that typically don’t involve combat, but when I describe Eastshade as a single-player, first-person, open-world game, people usually think Role Playing Game. And everyone knows that the particular role you play in a Role Playing Game is the role of a hero. And everyone knows that heroes live primarily in worlds where 90% of the population are wandering bandits waiting to be killed.
So the question “If there is no combat how will the game be interesting?” makes the same amount of sense to me inverted: “If all you do is kill dudes how will the game be interesting?” To a person who’s played mountains of games wherein you spend most of your time killing dudes, the latter seems like a ridiculous question. When you strip away the weird box thinking part about dude-killing, the question becomes “What will make the game interesting?” which is basically asking “Will the game be good?”.
So will Eastshade be any good? The game has changed a lot from what I initially set out to make. There used to be survival mechanics, which gave people something to grab onto when trying to understand what the game is (courtesy of Minecraft). Those mechanics are gone now. So what’s left? If I said its like a first-person, open-world adventure game it wouldn’t be totally off the mark. But the state of a traditional adventure game’s world is completely dependent on the player’s state through the game. The guard won’t move from the door until you do some absurd chain of lock and key puzzles to make it happen. Eastshade goes on without you, and the feedback from the world is more systemic, predictable, and granular.
What if I put it to you like this: Eastshade is not a game that you play, but rather a place that you go. There are daily solar and lunar eclipses, the conifers are purple, much of the architecture is spherical, and the people look like monkeys. Stuff happens. Do you want to visit?
I am now one year into the development of Eastshade, and something very important has happened. For the past three months, I’ve been focused on a small section of the game, determined to bring that one area up to a quality that is representative of what the final game might be like. In the games industry this is known as a vertical slice. Though the slice I have is not yet fully worthy of the name, within the last month, it has reached an important milestone nonetheless…
I now have a roughly playable piece of Eastshade.
Three months ago, Eastshade was a muddle of tech demos and disjointed systems. Many indie games are playable after the first two days of development. It seems mostly unanimous amongst game designers that the sooner one can produce a playable prototype the better, and I’m certainly past due on this. I could attribute my tardiness on this to the nature of the game I’m making, but my greenness as a game designer is more likely the culprit. As I’m careful to use wisely my stock of truly fresh eyes, only a few friends and collaborators have actually played through the slice, but from these few play tests, there is a general consensus that the game doesn’t suck! It came as a total surprise to me. My spirits are high and things are going well.
Because of how focused I’ve been, I feel I’ve targeted the essence of what I want Eastshade to be, and as a result the game has gone through massive mechanical changes. The addition of NPCs is a notable change. I’m currently working on an AI system for making the people of the world go about their daily business.
EDIT – This stuff is out of date now. I ended up replacing a lot of this stuff with my own solution.
The availability of amazing tools is helping us all make better games. At the moment, I’m mostly a one person team, but I’m not truly making a game by myself. If I make a fantasy cavern scene in Cryengine, to whom do I owe its beauty? My skills as an artist? The millions of man-hours that went into building the engine of which I had no part in? The fathomless ocean of computer graphics advancements that came before us of which I nor Crytek had any part in? If we are all creative snowflakes, then we are creative snowflakes that sit on a mountain of snow that has fallen before us. I want to talk about all the tools I’m using for the making of Eastshade.
At the center of this tapestry of game dev tools is the big U. In my life, I’ve spent considerable time in five engines: Cryengine, UDK, two proprietary engines, and the big U (fine I’ll stop calling it that). Unity is a game engine unlike any I’ve ever used, and I think its structure is revolutionary. Most engines have proprietary origins, and as a result, even publicly available engines seem built for a particular game, and then modified to be general. The legacy of fps is rampant in both Unreal and Cryengine. Unity is a general purpose engine from the ground up, and a blank slate like no other. Its framework is simple, modular, and extendible. Everything is a gameObject with components attached. Every component is a class that extends monobehaviour. If I dreamed up an engine, the engine would work like Unity.
Among the great benefits of using Unity is the asset store. Other developers have built fantastically modular systems that you can purchase for almost nothing and plug into your game. There’s never been a better time to be a one-man-band. Since I want Eastshade to have a unique aesthetic, I generally stay away from models/textures/music/UI graphics/sprites or the like. However, the extensions and utilities are invaluable.
UFPS – For me, the only price I paid for this asset was the time I spent learning how its insides work well enough for me to implement my own gameplay on top of it. Though I still get the feeling I’m not using it totally as intended, its player controller and input system are the backbone of the player controls in Eastshade.
Shader Forge – I actually would have had a really tough time building the look of the world without this extension. Every shader bar the foliage was built with Shader Forge. I wouldn’t have the chops to write something like a Y projection for moss and snow, or my own implementation of a global cubemap managing system had it not been for the simple node based workflow this asset provides.
Advanced Foliage Shader – The screen real estate that foliage takes up is considerable, and AFS, in addition to allowing my vegetables to flutter gracefully in the wind, looks beautiful.
DevConsole – A simple but important thing to have, I think, is a way to call certain functions from inside your game for debugging purposes. DevConsole makes it easy to define new console commands, even ones that accept arguments.
FogVolume – For all those foggy, foggy times. Inscattering has a big visual impact on long site lines (which you should have a ton of!).
SplineBend – I use this for all my roads and paths. I love how simple and open ended this asset is. I prefer it to EasyRoads for sure. Though I still use EasyRoads sometimes, not for building roads, but to shape my terrain oddly enough.
Shadow Softener – Soft shadows are nice, but nicer is the 10 fps I reclaimed when I started using this asset. Perhaps Unity 5 will negate the need for this asset, but currently soft shadows is essential for performance alone.
Every prefab placement painting tool on the store – I’m pretty sure I have them all now, but I’m skeptical to endorse any of them because none of them quite satisfy me. I’m half tempted to write my own at this point.
Honorable Mentions – I was using skyshop until recently, when I opted to use all my own shaders write my own cubemap controller. There were two reasons for this: The first is that Skyshop’s cubemap blending was more than I needed, as I found I only needed to tint my cubemap during weather changes, rather than switch to a new one. Lerping between cubemaps is pretty expensive, and I really didn’t like the implementation of how you just chose a blend duration and fired it off. I wanted my own night/day controller to drive the change. The second reason is that I found I never needed a full RGBA for spec and gloss (the skyshop shaders don’t allow you to pack the spec into an alpha channel). My last honorable mention would be Daikon Forge, which is a great GUI library, but turned out to be a massive mistake since the guy who made it just stopped supporting it. I made the call to switch to the new uGUI before moving forward with any more GUI stuff. I’ve been using the 4.6 beta and have yet to hit any showstopping bugs.
Git and SourceTree – This doesn’t belong in the Unity section but I’ve no other place for it. SourceTree is a wonderful GUI front end for the almighty GIT. It makes working with version control a lot easier for someone like me, who doesn’t wish to dabble in a command line console to submit and revert files. You may be wondering, “But aren’t you one person? Why do you need version control?” If your spending a lot of time on something its wise to be making iterative backups as you go, and as long as your making iterative backups you may as well be using an application to manage them. Version control is designed for that. I can’t tell you how many times I’ve needed to look into previous revisions after realizing I’ve messed something up.
Blender – I first learned the ropes of 3d with 3ds Max, and then spent my professional career as an environment artist so far using Maya, but despite having sunk so many hours into these other industry standard tools, I prefer Blender over them. I wrote a special exporter to make getting my stuff into Unity as easy and fast as possible.
Photoshop CC – I was using Gimp to save some money, but since Adobe did the 10 bucks a month thing I switched back to the tried and true. After using Gimp extensively, I can honestly say it has a long way to go before comparing to PS. All you have to do is try adjusting the levels of a 2048 and watch Gimp slowly loop through all the pixels line by line each time you nudge a slider to be convinced.
Unorthodox Game Dev Tools – If you’re a game artist and haven’t heard of this Photoshop plugin you should definitely check it out. Its the sweetest texture export plugin I’ve ever used, and its author is a nice guy, very responsive, and helpful.
3d Coat – Aside from being an excellent sculpting package, I love being able to drop a totally garbagy mesh (perhaps from a photo scan) in there and convert it to voxels, then convert it back to polygons and decimate it. I also use it for unwrapping organic things like rocks and tree trunks. Its got the best seam making tools I’ve ever used.
Lots of other things – I use quite a few other little programs for content creation often for very specific tasks. Among them are CrazyBump for texture creation, PhotoSculpt which can derive a height map comparing two photos of slightly different angles, and automagically tile textures with normal map and all, and the fairly obscure (and free) MeshLab for its incredible UV-preserving mesh decimation features.
I think that’s most of the stuff I’m using. If people find this technical blog post interesting I could write more about my technical challenges, and show some tools I’ve created myself for my own needs, but I don’t want to pollute this blog with content that doesn’t interest people, so if you guys could let me know if you dug this I would appreciate it!
EDIT – Much of the information pertaining to the game in this post is outdated now. The game has been evolving and its not the same as it was at the time this was written. The vitality bars have been removed. The inventory menu has been redesigned.
I’m a subscriber to the up-and-coming idea that games have potential to invoke a much broader range of emotions than what we’ve been seeing so far. Jenova Chen has pointed this out very eloquently in a number of interviews and talks. One emotion that I’m consciously trying to procure in Eastshade is safety. I think this medium is particularly suited to do this effectively, since in a game, one must overcome danger themselves, rather than sit back and watch events unfold as in a book or movie. In traditional RPGs, I love the feeling of returning to the safety of an inn after surviving a treacherous dungeon.
To effectively create that wonderful feeling of safety, there has to be some danger. While there are no hostile AI in Eastshade, the world itself is as dangerous as it is beautiful. You have to pay attention to your malady, cold, exhaustion and hunger, and as you travel, you’ll deal with “conditions” that the environment will inflict on you. Jumping in water will make you wet for some time, which makes you colder. Walking without boots in rocky tide pools will give you a deep cut, which continues to affect your Malady bar until you bandage it. The tent pictured above, safely perched on a seaside bluff, restores the players exhaustion, and the fire keeps them warm.
Of late, I’ve been working on inventory systems and GUI. On the left is your stuff and on the right are the schematics you’ve acquired (crafting recipes). At the bottom are your vitality bars. The lovely icon art is being made by my girlfriend, Jaclyn. She’s an artist as well. Our avatar is doing pretty good at the moment. On each side of the vitality bars are equipment slots. You won’t be able to equip an acorn (as indicated in the image), because I tried equipping one in real life today and it had little effect. For some reason I thought it would give me resistance to poison. Provided you’ve the schematic and the necessary materials, you’ll be able to create vehicles (a means of travel) and gear (protection from some of the “conditions” the environment will give you). Items will be sprinkled throughout the world, but the schematics will be particularly valuable, and will primarily be acquired by reaching new places. I have a novel idea for the way which rewards are delivered but for moment I don’t want to talk about it until I’ve actually tried implementing it. I will say that whatever this delivery method ends up being, it definitely won’t be a loot chest.
Currently, I’m diligently at work on the dynamic night and day cycle for the game world. Soon I hope to have a video showing, among other things, the ominous celestial eclipses that happen twice a day on this strange planet. Of you who have taken interest in Eastshade since its humble unveiling two weeks ago, I know at least some are eager to see a video! But for now I’ve only this single morsel.
It’s been about six months in the dark, and I think its time I showed people. I’m making a game about exploration for exploration’s sake. In most open-world RPGs indeed you explore, but it doesn’t quite feel like you’ve found anything unless there are things to kill there. The rewards received are almost invariably items with which to kill more effectively. Even side professions often yield rewards that aid you in killing one way or another. To put it technically, I’d like to attempt to make a game where the core reward loop is exploring itself. Exploring rewards you with things to help you explore more. As the combat in other RPGs can be a worthy experience itself, rewarded or otherwise, traversing the environment will be the worthy experience in Eastshade. I have some ideas about how I might make a world interesting without combat, but I’d be delusional if I held any certainty about it all working the way I plan. There are likely going to be changes along the way, and what I end with may not be what I initially set out to make (I’ll be elated if I can manage to end with something at all). I invite anyone reading this to come on this journey of making something weird with me, perhaps to see it turn into something worthy, or perhaps to see it train-wreck spectacularly.