We’re Starting a Video Devlog!
Hello everyone!
Development is going strong, but release is still a ways off. To tide you over in the meanwhile, we’re starting a devlog! In this series of videos we’ll cover what we’ve been up to, behind the scenes clips of our process, as well as some philosophy and just generally things we think about when designing the game. We hope you like it!
And please feel free to subscribe to our channel on YouTube if you want to catch the future devlogs! And of course liking and subscribing helps us out in the YouTube algorithm so we’d greatly appreciate it!
Our New Game!
And FINALLY! We’ve been bursting to show it to you all! Don’t forget to wishlist!
It’s been 3 years since the initial release of Eastshade. Time has flown! Jaclyn moved on to our new game soon after release, but I didn’t officially move off Eastshade until September 2020, about 1.5 years after its initial release (patches, porting, admin, ugh!). Jaclyn played a massive role in the development of Eastshade on nearly every level, but Eastshade was my baby, my dream. Songs of Glimmerwick is Jaclyn’s! She is helming the design, writing, and art, and I do programming/technical direction and some design/writing.
The game looks different from anything we’ve done (perhaps different than any game I’ve ever seen period?), which is hugely exciting! Despite its different appearances, I think people will feel our distinct life force in the game, particularly in our commitment to building a sense of place, explored through non-combat mechanics, which is the mission statement for our studio after all! We are so excited to be able to talk about it. And I am personally excited to get back to streaming on twitch!
Not Eastshade 2
Okay folks. I’ve got to get something off my chest. We are indeed working on a new game. And its not Eastshade 2. In fact, its not connected to Eastshade at all. It will look nothing like Eastshade in its rendering or its art style. It isn’t even first-person. There will be similarities. Its another lively world full of characters and stories, and once again will not have any combat loops. We feel it will again be a place you’d want to live. It will, of course, still have plenty of books and tea (we’re not monsters). I can’t tell you how excited we are about it.
We’re asked weekly if we’re working on number 2, sometimes even so bold as “so when is Eastshade 2 coming out?”. I’ll admit I often ignore the question, as I know there are some folks who would really look forward to a number 2, and I don’t always, in the moment, have the heart to crush that hope so thoroughly by answering. But occasionally I have answered folks with the truth, and despite my fear of disappointing, so far none have been anything but supportive and excited. So I think its time to put it out there. We are wholly devoted to something different now, and there is no number 2 planned. This is not a reveal. We’re not ready to show anything just yet, and we certainly don’t have a release time frame in mind. I just wanted to let people know what’s up, and perhaps quell any anticipation there is for a potential Eastshade 2.
I want folks to understand that the change in direction is not a calculated one. Its not a business decision. We’re just doing same thing I did when I started Eastshade Studios—We’re following our artistic whims where they lead us! Fortunately, I have found fans of Eastshade to be an open-minded bunch, and I hope people will love what we’re cooking up, even if its in many ways different from our past work.
Postmortem: Eastshade
Eastshade is an open-world, first-person adventure game where you play as a traveling artist. It was released for PC on February 13, 2019, and for Xbox One and Playstation 4 on October 21, 2019.
Quick Facts
- Game Engine: Unity
- Platforms: Windows, Xbox One, PS4
- Eastshade Studios’ second release, following our small spinoff title Leaving Lyndow.
- In development from 2013 to 2019
- Metacritic 78, Steam score 89 (at time of writing)
- Initial budget of 200k*, plus additional 60k post launch for porting and patching
- Self-published, funded from personal savings + help from family toward the end when we nearly ran out of money
- Roughly $2M USD gross revenue across all platforms so far (1.5 years since launch)
* Most of the budget was for living costs, while living as cheaply as possible. If a publisher asked us to make a game like Eastshade for 200k we’d laugh at them. A bare living cost style budget is not really comparable to an actual hiring budget. If we wanted to convert this budget to its actual economical value, it would have been more like 700k.
The Beginning
I landed my first game studio job in 2010, and ever since then I knew that one day I’d want to make my own game. I always assumed it would take a lot of money, and that no publisher was likely to hand it to me to try, so I saved religiously. Assuming I’d have to hire a team to build something substantial, I thought it was going to take a very long time to build up the funds. But my outlook changed in 2013, when I saw a number of indies creating impressive products solo or near solo.
I’d been working on what would become Eastshade at home in the wee hours for months, and was making good progress. My inspiration burned so hot, I was finding it hard to get to bed, which resulted in a severe lack of sleep. Some people can manage to work on their indie project while holding a regular job, but I’ve always had a very single-project mind, and struggle with multiple projects. I knew I could only keep doing one. With years of savings stockpiled, in December of 2013 I quit my job at Sucker Punch Productions as an Environment Artist to go full time on Eastshade. I knew I could pinch pennies to make the savings last, and with no children or mortgage my tolerance for risky financial moves was high.
The first year of Eastshade development was a very special time in my life. Imagine a moment of pure inspiration— the feverish kind that burns so hot it gives you goosebumps (maybe that only happens to me). I felt that burning inspiration every day. The inspiration waned slightly each year, and eventually gave way to commitment, which, as it turns out, becomes easy to hold when you’re 3 years in and have invested your life savings. In the last year, when I had sight of the finish line, neither commitment nor inspiration seemed required, as the thrill of finishing and releasing—the moment I’d been fantasizing about for so long—was all I needed to keep swimming.
Team
I started the project alone, but fortunately I didn’t have to finish it alone. By the second year my partner Jaclyn was making major contributions in design, writing, UI art, and in-game illustrations. By the fourth year she was working on the project full-time and doing quest markup, mapping, and testing. Most of the game’s hallmark mechanics were of her conception and design, including the painting mechanic itself, as well as the inspiration mechanic. In addition to her high level art chops, she has grown into the best game designer I know, and it’s safe to say the game would have been wholly unrecognizable without her.
Beyond myself and Jaclyn, our composer, the amazing Phoenix Glendinning, has been working closely with us from the start. We also had a character artist, Daniel Merticariu, who was an army unto himself, and single-handedly modelled all the outfits and characters. Toward the end of production we hired two quest scripters and a programmer to help us implement quests and get the game across the finish line. Finally, we worked with a number of additional contractors, including voice actors, translators, DO Games who handled our console ports, as well as our publicist extraordinaire Charlene Lebrun of Player Two PR.
Design
Throughout Eastshade’s history, there were a few eureka moments of design. I’d always known I wanted to make a game that was a place. A strong sense of place is my favorite thing a video game can give, and it is, and will always be, the main design pillar of any game I have authority in designing. And I knew I wanted it to be a nice place, where you could feel cozy and safe.
In the beginning the idea was to make the game’s core loop through survival mechanics. We had hunger, coldness, energy, and the idea was to build progression with finding things to help these depleting bars. We had come to our first major design dilemma: The constantly depleting bars were entirely at odds with how we wanted the game to feel. They penalized the player for doing the very thing we wanted the game to be about, which is going slow and feeling that sense of place. We needed a new core loop.
The painting mechanic was born from trying to think of a way to reward the kind of thing we wanted the player to do in Eastshade, which is to go slow and smell the roses. One fateful day, about a year into development, Jaclyn came up with the idea that the player could be a painter, and create quests around the player capturing certain objects, places, colors, times of day, or a combination of those. This would work in perfect harmony with wandering and smelling the roses, because the slower the player went, and the more they let the sense of place wash over them, the better they would do at these quests. It was genius. That was the first eureka moment in our design journey.
The next eureka moment came about 4 years into development, and although it’s a less prominent feature, to me, was even more momentous. It was the type of idea that doesn’t make new work, but rather solves existing problems. It was the inspiration mechanic. The idea was that creating paintings would cost inspiration, and new experiences in the game world would give you inspiration. So drinking tea, reading a new book, discovering a new location, relaxing in a hot spring, hearing a tale from a story teller, listening to street music (basically exactly the cozy stuff we wanted the player to be enjoying) would all reward your player character with inspiration.
This totally closed the game loop, created a harmony between theme and mechanics, and gave us an easy way to tie all auxiliary actions into the core loop. It was, again, Jaclyn’s genius. It was amazing that such a tiny and easy to implement feature could have such a profound impact on the game, and that it came so late in development, yet fit like a glove. It made me realize the true power of a good idea. Ideas that come in the form of more content, or at the cost of production resources are a dime a dozen. I have hundreds of ideas of that nature lying around. But an idea that solves problems is precious.
Marketing
For as long as we’ve been working on Eastshade itself, we’ve also been working on its promotion. I don’t think there’s any one or two things that are the magic bullets, because every game has different avenues that work for it, and indeed, the marketing effort is the sum of its parts. I’ll try to give a rough outline of the things we did for Eastshade:
- We hired Player Two PR who handles press releases, journalist outreach, strategizing on release timing and plan, and key distribution during big moments in our campaign.*
- We picked our timing for our trailer releases, our release date announcement, and our actual release (the most important one) very carefully, trying to stay clear of other news and releases.
- I am very active on Twitter (@eastshade), posted lots of screenshots and gifs, and interact a lot.
- I often streamed my work on twitch.
- I’ve written a number of articles that have done well on Gamasutra and 80.lv and other game dev sites.
- We got into the Indie MEGABOOTH at PAX West, and also showed at GDC in a special Unity booth we were invited to for the 3D Game Art Challenge. I feel the impact of conventions is often overestimated, but we ended up getting some important coverage, especially at GDC. I guess every time you do a convention you are rolling the dice that you might get some big coverage.
*Number 1 is big. Charlene (who is the founder) knows the games media landscape well, and in addition to all the regular PR stuff like press releases and key distribution, does a lot of research as far as finding people who might be interested. Perhaps most importantly, she helped us with our grand strategy in terms of what marketing assets we needed, how we should roll things out, and the timing of everything.
That is the outline of things we did on the promotion side. There are a lot of other things that go into it, but that would be a whole article itself.
Revenue
And without further ado, the moment you’ve all been waiting for! With myself and Jaclyn the only full-timers on the team, and under 100k in contractor investment, I can say that Eastshade was a massive success for us. Across all platforms we have grossed about $2M since launch. That translates to about 1.1M post-platform net. Our deepest discount so far is 50%, and our sales curve is still very healthy. We expect to break 3M gross in the coming years. Most platforms have NDAs regarding revenue stats, but Steam now lets us show ours. So here it is:
Steam is by far our biggest market share. In fact, I would call our console launch a faceplant. Our sales were about 10% of what we expected them to be. A few months ago, we were fortunate that Microsoft featured us on the family homepage, and Xbox sales have picked up substantially since then. Playstation has remained a trickle, and our PS4 release was hardly worth it for us, especially considering what a difficult platform it is to release on, from both a development and administrative perspective.
What Went Right
Going Indie
If it’s not obvious at this point, going indie turned out to be the best career decision I’ve ever made. It was only last year that true financial stability arrived from that, but the real change in my life happened when I quit the day job. Despite the uncertainty of not knowing if the game would succeed, it was still a much happier lifestyle for me. I love being able to make my own game, call my own shots, and work on every part of production. I also love working from home and having a more flexible schedule. There is virtually no part of being indie I don’t like more than working in triple-A, except for maybe porting, business accounting, and taxes.
Vertical Slice
During the first few years of development, we focused on the first area in the game, and kept polishing until the chunk was playable and somewhat representative of the final game. It was probably 20% of the total map size (for those who played, it was the Lyndow area, all the way to the toll bridge). Having our vertical slice segment be the beginning of the game was great, because it meant we didn’t have to tell people how to play, or try to get them up to speed; since it was actually the beginning, the game was already naturally doing that.
I think this also helped us see how good the game actually was. I feel adventure games are never very fun when you pop into the middle without following the threads from the start. I’ve actually become a big fan of building things in the order they come. Sometimes when I’m lost and don’t know what the most important thing to work on is, I find it helpful to simply start from the beginning, and work on the first thing you encounter that is missing or broken.
Team size
I really enjoyed developing the game with a micro team. I have found I’m not a fan of delegating or managing, and feel I’m bad at keeping others busy and energized. Additionally, the added pressure of scaling up the payroll is not something that appeals to me. You have to make sure you release that much faster, and sell that many more copies.
Outsourcing things like porting and PR have worked fantastically, and we’re hoping to go even more in that direction for our next title with adding QA to that list as well. But as far as core development, I feel just Jaclyn and I can move mountains, and don’t feel particularly limited by our bandwidth there. I’m not saying we’ll never try hiring more, but I’m glad we ended up keeping it small for the majority of Eastshade’s development, and we will be very careful about expanding in the future.
Outsourcing the Console Port
I ported Leaving Lyndow to PS4 myself, and it was easily the most unpleasant 6 months of my career— possibly of my life. Jumping through hoops, reading documentation, filling out form after form, all while identifying proprietary unexplained vernacular and protocol is just not my strong suit. I felt very lost at sea during the whole process, and it took far longer, and was more frustrating than I ever could have imagined.
DO Games was a lifesaver for us. Matt helped me with the loathsome admin side as well as spearheading the technical. Eastshade was not easy to port. Despite all the performance work I had done over the years, it was not enough for consoles. The fact that I had already gotten all the low-hanging fruit made squeezing that last bit even more difficult.
I actually think maybe we did not outsource this task enough. Which is to say I think it would have been more pleasant for me if I had actually let our partner publish the game as well, thereby offloading any and all admin tasks. Even if we had given away a larger share of revenue to do that, it would have freed me to move onto our next title, and I think less mistakes would have been made due to my scatterbrained incompetence.
Twitch Streaming
I often streamed my work on Twitch, to an average of 30-50 viewers.I think this helped us grow some dedicated fans, who experienced a connection to the development journey. When we were ready to launch a closed beta, a good number of the folks who participated were regulars in the stream, and their feedback was critical. We are hugely grateful to them for taking the time to play through those rough early versions of the game.
More than that though, I felt streaming actually helped me stay laser focused for hours at a time. It’s easy to stay focused when people are watching, and the desire to make progress quickly for a more entertaining stream helped me work with even more intent, poise, and speed. I’m a little sad that our next project is too early to show, because I really miss streaming!
Streamer Testing
We only ended up doing one of these, but holy smokes was it valuable! We put out an application looking for small/mid-sized twitch streamers to do a private playthrough for us (paid). Streamers are perfect because they have the setup necessary and are accustomed to talking through what they’re doing, which helps us take notes and learn. We will absolutely be doing more of these for our next title; hopefully throughout the entire development process. There is just nothing like watching someone with totally fresh eyes play your game in real-time, and with friends and family you use up your immediate pool of fresh eyes pretty quickly.
Voice Acting
The first time we tried adding a voice to an Npc in Eastshade, it was revelational. It made talking to the character hugely more exciting, and, to me, added a whole other dimension of exploration. Not only do you find new people with new things to say, but new voices as well. It added a ton of personality to each character, and picked up some of the slack of our stiff character animation.
I initially thought full voice acting would be prohibitively expensive, but I found that to be completely untrue. We voiced all 50 characters (around 25k words) in Eastshade for around $10k USD. After a round of careful casting, we let each actor self-direct, and we were extremely pleased with the overall quality achieved that way. We have gotten a few complaints from players about the acting quality, but something I noticed: Every game with acting has people complaining about it. Even games with top tier talent seemingly have numerous complaints about it. Acting quality seems to be very subjective, and prone to being judged by its worst performance, and it’s something players love to criticize—so I don’t think the criticism we got is actionable or worth considering.
Focusing on Characters and Quests
At first we toyed with the idea of making the painting system more robust. Perhaps adding XP, upgrades, different kinds of paints and brushes—but I truly feel we served our game best by keeping it simple. It freed up our development focus (and the player’s focus as well) for interesting quests with unique characters. We feel this is where all the personality of the game comes through, and is the primary reason why people love to explore our little island. I feel like the quality of our quests, in terms of novelty, player actions, and personality is up there with any of the great quested games I’ve ever played, and I aim to make that part of our studios brand.
What Went Wrong
Launch Bugs
We had quite a few bugs when we launched. Even now a few remain. So what could we have done to prevent the bugs for Eastshade? In hindsight, honestly, nothing. As I look back on the final months of production, I do not believe we could have prioritized any better. We cut exactly what we could cut, and got all the right bugs and polished all the right things with how much time/money we had left. And I most certainly cannot say we could have worked any harder. I do not think hiring QA would have been particularly helpful, as our bottleneck was diagnosing and fixing the bugs, rather than knowing of them. Our most time consuming bugs were the ones I am confident QA would not have been able to identify a repro for.
A lot of the biggest bugs were fixed within the first few weeks after launch, but the scars remain in our review scores. While I’m not sure it could have been helped on Eastshade, bug fixing is something we need to plan more time for and devote more energy to on our next title.
Regression Bugs
Post-launch, I would occasionally drop an update and about 6 hours later find in horror that I had broken something somewhere in the game. One of the most tedious parts of releasing an update was actually testing. Both Jaclyn and I got to the point where playing the first few hours or so of Eastshade to make sure there were no regressions was quite a loathsome task. It would have benefited us to run through the entire game to verify updates, but this would take nearly a work day, and neither of us could bear it. I think this sort of verification testing would be a good avenue for outsourcing. If we had a partner QA house who could handle this, they could rotate testers, and it wouldn’t be quite as horrible for someone who hadn’t run through the game 300 times already. It would also free us to keep polishing other parts of the game. I’ve also heard of some studios successfully automating their testing, but the notion of that sounds pretty alien to me (basically making an AI that can play through the game). Maybe that’s an avenue I need to look into.
Version Control
It’s kind of a silly thing to get wrong, but we struggled with version control nearly the entire project. We used Unity Collaborate for most of development, and it was an ongoing nightmare. We wrestled giant changelists of files that had not been changed, server issues that could only be resolved by ferrying changed files to another workstation and then reverting, absurdly long check-in and sync times, and a plethora of other day derailers. It was a very serious source of day-blockades for the project. At one point I attempted setting up Perforce on an Amazon server, but after two days of tinkering it seemed the rabbit hole was going to be so deep, and the learning curve so steep, that it would take too much time from development.
I wish we had ditched the idea of using a cloud server at all. For our new project we are using Git and Sourcetree on our local network, and it has totally changed our lives. With the speed of a local network, it takes mere minutes to sync. On the one hand, storing data locally seems risky, but if you’re abstaining from checking in for days because you’re scared something will get stuck, or the commit will take 30 minutes, that is actually more risky! We just need to remember to back up our repository every few months, either online or on a flash drive stored somewhere other than our house, and that way we have some insurance in case the house burns down. In reality, the biggest risk for data loss is file corruption, or hard drive failure, and since Git is decentralized, we are always protected against that, since every workstation has a full copy of the repo.
We Got Ransomwared
I’m not sure this is necessarily post-mortem material, but rather just a story I wanted to catalogue. It’s true. Yours truly actually fell for a ransomware email. It was the Locky Virus, and it came in the form of a fake invoice. I had never seen or heard of ransomware up to that point. I opened the attached file and off it went, encrypting every file on my workstation. It got through about half my files before I realized what was going on and pulled the plug on the computer. What’s worse—it was in 2016, and I was not using any version control at the time, other than Google Drive. And the Google Drive client had already been busy detecting changes and uploading all the encrypted files—overwriting the old ones on the server.
That was it. Those were all the places the project was stored at the time. For a few hours, I actually thought I’d lost Eastshade, 2+ years in the making at the time. I remember I called my brother at 4 am, who was trying to console me that typically paying the ransom on ransomware actually does decrypt the files, since, in a sick way, they do have a “reputation” to uphold for future ransomware victims.
It was a terrible night, but eventually I found that, astoundly, Google Drive actually does have a version history. There was no batch tool to download old versions of thousands of files, so it was just a tedious matter of going through each file and downloading the previous version manually. It took a few days, but after the night I had on the mountain of solitude when I thought I had lost it all, I did this task with joy and a renewed passion for life.
Things That I Am Still Unsure Whether They Went Right Or Wrong
Animal Folk
I suspect we just shouldn’t have done it. I was taking a page out of Elder Scrolls. I thought it would make the game feel more unique to have animal folk. And it did to a certain extent. We started to realize the mistake after feedback from Leaving Lyndow, prompting us to make massive improvements to the designs for Eastshade, but I don’t think it was enough. It was a huge turn off for so many people. It’s hard to quantify how many potential players we lost for this, but it really wasn’t an important aspect of the game, so no amount was worth it. I’ve always cared a lot more about what the Npcs say then how they look, and the game would have been much the same with normal humans.
If we were going to go the animal route, they should have been considerably more stylized, with bodies more like the animal. The issue with that is that it would have required unique rigs for each character, and therefore a unique set of animations. I’m not sure we could have pulled this off, me doing all the animations and rigging, which is something that is not at all my wheelhouse. And I suspect it would have been prohibitively expensive to find an animator for this on the industrial scale we needed. So we probably should have gone with regular humans.
Self-Publishing
On the one hand we didn’t have to give away substantial portions of revenue, but on the other I was stuck doing a lot of things that aren’t game dev; most of which I don’t enjoy. What I’m still unsure of is if a publisher would have truly offloaded these things from me, or if I’d be stuck doing parts of them anyway in one way or another.
I’m sure they would offload some things, but I’m not sure if it would be enough to account for the type of percentage most of them take (tends to be 30% for a non-capital fronting publisher). I suspect the best reason to go with a publisher is still if your primary need is development capital. It was tight but we made it, and we certainly don’t need capital now. I’ll also never know if the audience of an established publisher would have springboarded us into a substantially bigger sales curve, or if we made enough of a splash that most of our market found us anyway.
Release
The tale of Eastshade’s launch day is an odd one. I have been wanting to catalogue it somewhere before the details of it vanish to the decay of memory. The tale begins, as many epic tales do, with some backstory.
In the final year of our five-year development, we were beginning to run out of money. With both Jaclyn and I working full-time on the game, we managed to stretch our savings quite far, but eventually the well was running dry. My mother and grandmother, who live together, very graciously offered that we come live with them. Bless their hearts! This helped us tremendously, and ensured we had enough reserves for final launch costs like localization.
My grandmother’s house is a bit rural, but the internet is fast, and continuing development there was never a problem. But on launch week, something truly rare happened. It snowed. A lot. In fact it was the 3rd biggest snowstorm in the Seattle area in the last 100 years. The day before launch we lost power. No problem, right? Just pack up the computer and drive as far as you need to to find power and internet. The problem was there was about 1 mile of private road to leave my grandmother’s house. With over a foot of snow, just about any car was hopeless, and no snow plow was coming.
We considered our options. The first thing we tried was driving over the snow. We made it about 20 feet before losing traction and starting to drift sideways, toward a ravine (fortunately this was still in the driveway, so we could leave it there). Next we started shoveling a path. Anyone who has shoveled snow probably is finding that notion quite laughable, because shoveling a mile of snow by hand is not really feasible. It only took a few feet of shoveled road to understand that.
Running out of ideas, we considered gathering our things and hiking out to the main road, and summoning a family member to pick us up. But among other logistical issues that are too tedious for this story, the roads were in no state for anyone to be driving on. Snow isn’t a huge problem in places that are prepared for it, but in the Seattle area, even a little snow is basically the apocalypse, and we had a foot of it.
In the end we decided we’d wait and pray the power returned before 7am the next day, our scheduled launch time. We did have a build I had uploaded a week prior, that was in a somewhat launchable state. Over the phone I was able to get my brother (in a neighboring city with power) logged into the Steam partner site, ready to hit the launch button if power didn’t return to us in time.
It was a dark moment for me. It wasn’t so much that I was worried things would go badly without the most up-to-date build (though I was worried about that), or that people wouldn’t be understanding of the slightly delayed updates due to our snowstorm situation, but just that I had been dreaming about launch day for five years. I had always envisioned being able to watch it all unfold from my own workstation, with my own internet. I found myself on the eve of our launch not even excited about the big day, but rather just praying through gritted teeth that the power would return.
At 4:30 am, just 2.5 hours before our launch time, the power returned. I uploaded the latest build with the force of a thousand well-lit rooms. And by the guiding light of electricity, I went into the kitchen for a pre-launch snack. There, on the counter, I found this:
While I was trying to jump start cars and shovel snow the night before, Jaclyn had secretly made an Eastshade pie by candlelight. Of uncooked oats, peanut butter, and honey, she had made the only thing she could come up with without an oven or burner. I cried like a baby. In all the madness I hadn’t thought to do anything to make the day special or memorable. I was too worried about the power to savor the momentousness of the occasion. When I saw the Eastshade pie she had thought to make, it finally felt like a special day. Even now if I think about that pie I tear up.
As far as the launch itself, it went pretty smoothly, all things considered. We did have one absurd bug with the Russian localization which we fixed within a few hours. A few days earlier we caught that some of the text fields were overflowing in Russian, so I scaled the Russian font down globally to 90%. On my ultra-quick verification test everything looked dandy, but if I had kept playing another minute I would have seen a ridiculous problem. I was doing 90% of the current font size. The result was the font shrank a tiny bit each time the text field was repopulated. Until you get something like this:
For months I was getting bug reports of that, because all the torrent sites instantly uploaded the 1.0 version of the game, and many of them didn’t bother to update, even though the fix came within hours. It made it very easy to spot the pirates.
Conclusion
I’m hugely proud of Eastshade. It’s a bigger and better game than anything I envisioned when I first started it in 2013. I am so fulfilled by its completion, that if I died tomorrow, I would be content with what I did with my years. To be clear, I’d very much like to keep living, but that is the level of impetus I felt to complete it.
In the months following its release, amidst the joy of finally achieving some security as an indie, and the warmth of its reception, a small part of me did feel off. It was the forward-looking part of dreaming about what Eastshade would become. It may sound a bit one dimensional, but for five years, I saw many things in life through the lense of being excited for Eastshade. If I saw a beautiful building, I’d think “Ooh we could do something like that in Eastshade!”, or if I heard a street performer, I would think “Wow wouldn’t it be cool if we had street performers in Eastshade?” All forms of inspiration were impulsively funneled into dreaming about the game. When it was finally released, I was a little unprepared for the quickness with which that habit had to die. “Oh that would be cool in Eas- oh right… It’s shipped and done, and whatever it is will always be,” I thought, as I found myself unexpectedly wistful about things that never came to be in the game. But you can’t keep working on something forever. And please don’t advise me to keep working on content updates for our fully released, single-player, barely replayable game with a regular decaying sales curve :)
Eastshade Studios is now a fully self-funded game studio free to work on our own products. We are a game ahead of our capital instead of a game behind (meaning our revenue is stockpiling for our next game, instead of going to pay back a publisher or investor from our last), which means we can go wherever our whims blow, instead of needing to seek more funding. While we intend to expand our budget a bit for our next title, we also intend to store some nuts for winter, and put ourselves in a position where one flop won’t kill us. It’s an exciting place to be! And we have every intention of our next game blowing Eastshade away in scope, polish, variety, coziness, wonder, and personality!
Eastshade is Coming to PS4 and Xbox One!
Eastshade will be available for PS4 and Xbox One on October 21! While our core team has been busy squashing bugs and delivering updates, our partner DO Games has been hard at work bringing the world of Eastshade to consoles. It has proven to be a behemoth task, but we’re finally closing in on the finish line. In under a month you can play this open-world travel simulator paint-em-up from the comfort of your sofa! Accompanying this announcement we bring you a new extended trailer:
Eastshade Gets a Release Date and a New Trailer!
Howdy all! After five years of toiling away on this weird world, we’re excited to bring you the news that Eastshade will be released for PC on February 13th, 2019. Without further ado, I present our shiny new trailer:
Voice Acting Casting Call 2!
Its time for our second round of casting! We’re in the final stages of production. Quests are being tested, bugs are being squashed, and scripts are being finalized. And we have over 40 characters that need voices! So without further ado, here is our Eastshade open audition casting call. Please be sure to read the briefing closely!
A Call For Streamers!
As we approach the final stages of production, we’re finding ourselves in need of additional testing. There will come a time when broader testing is required, but at this stage in production, something that we’ve found invalueble is the ability to watch a fresh player play our game in real time. This is different than letting players play by themselves and then offer feedback, because we’re able to more easily identify bugs when we’re watching, and perhaps more importantly, easily identify the lowest hanging fruit in terms of avenues for improvement.
We’ve run out of local fresh eyes, so we’re looking for remote ones! Streamers are perfectly equipped with the gear and skills required to stream their session and talk through what they’re doing as they play. How this will work:
- First we’ll have you sign an NDA
- We’ll schedule a session, likely a couple hours
- You will stream us your play privately over discord.
We can offer 15 USD/hour, and will pay you via paypal. It would likely be 2-8 hours total, over multiple sessions. We’ll pay you for time you spend in the sessions plus an additional hour to cover any setup time. I have no idea how many will apply, and we’ll be taking people in rounds one at a time, so we have time to make improvements between sessions. So its likely we won’t be able to accept everyone. We require the following:
- A link to your twitch/youtube channel (so we can see examples of your setup quality)
- Reasonable video and audio quality (we care about screen only, webcam not necessary)
- A great internet connection
- A solid pc, as the game isn’t fully optimized yet
- Ability to think out loud as you play
- A discord account (or for you to make one)
Basically we’re after a fairly regular single-player stream like you’d see on twitch, but in a private setting. If you’re interested, please apply here.
Eastshade will be at PAX West!
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!
We’re looking for a Quest Scripter/Coder!
UPDATE – Thanks everyone! The position has been filled!
Hello, everyone! We’re looking to increase our bandwidth for implementing quests. We’re looking for someone who’s excited about Eastshade and loves authoring/implementing quests! Its a bonus if you have writing chops, but more importantly we need someone who can actually implement quests in Unity within our framework. If you’re interested, find out more here (link removed, position has been filled!)
We will be at GDC!
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!
Steam Page and Trailer 1.1!
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.
Foliage Optimization in Unity
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.
The Problem
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.
The Plan
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.
Atlasing
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.
Grouping
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).
Combining
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
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.
Shading
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.
Light Baking
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.
Miscellaneous Tricks
- 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.
Conclusion
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.
Voice Acting Casting Call!
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.
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 Postmortem
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
Game Length
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.
Conclusion
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.
Quick Facts
- 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
Art Tips for Building Forests
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.
Reference
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.
Clustering
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.
Trunk Density
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.
Dead Things
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.
Trunk Bases
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.
Undergrowth
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
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.
Particles
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.
Time Wasting
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.
Conclusion
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.
Leaving Lyndow has Officially Launched!
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!
Leaving Lyndow Announcement
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!
Creating a Dynamic Sky in Unity
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.
Sky Composition
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.
Not Done!
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.
Press Roundup
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.
English coverage:
- Kotaku
- PCGamer
- Kotaku Australia
- Adventure Gamer
- Gamersyde
- IndieGames
- OnlySP
- GameWatcher
- A Handsome, Trustworthy Blog
- Future Beta Gamer
- Gamesear
- Gaming Illuminaughty
- Killscreen
- The Golden Cartridge
- Indie Game News
- Gamers FTW
Non-English coverage:
- 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)
First Official Trailer for Eastshade
After over two years of development, we’re proud to present our first trailer!
Not a Walking Simulator
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.
A First Look at Painting
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 Wide World – Building a Foundation
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!
Tissue Testing
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!
3d Art Time Lapse – Making a Building
In an altogether unfocused effort to share my development progress, I present… Dev Lapse 2! This one doesn’t document my culinary expertise, however, in this 10 minute production, I share part of my process for making a virtual building!
I also present a new screenshot:
Crafting Conversations
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.
The dialogue interface. The character model is a work in progress.
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.
The markup language. Perhaps “string data format” is a more suitable name for it.
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…
This is a fake conversation to demonstrate how the system works.
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.
A medium size conversation.
Without Combat, What Do You Do?
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?
The Vertical Slice and a Dev Lapse
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.
Tools Used in the Making of Eastshade
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.
Unity
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.
Content Creation
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!
Surviving in a Strange World
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.
Nightfall
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 begins…
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.
