Dear Esther and Unity

Originally Posted February 14, 2014

So I posted a GIF on twitter a couple of days ago, and as some of you will have already noticed, it shows Dear Esther running in Unity. It’s a project I’ve been personally working on for around 2 months now and I think it’s finally getting to a point where it’s worth talking about.

So you’re probably thinking: “Why would you want to port Dear Esther, a fully finished game, on a solid engine, over to an entirely new engine so late after release?!”. Allow me to explain…

Dear Esther was originally made with a miniscule team, consisting of Dan Pinchbeck: writer and creative director, Jessica Curry: composer, Jack Morgan: contract coder and myself for everything else. When I originally took on the remake of Dear Esther it was a mostly solitary effort; with the mod already released and all of the groundwork materials in place, the main meat of the task was to overhaul the art and level design. However, as ambitions grew so did the scope of work. Having no resources for hiring outside help, it meant us taking on as much of the extra leg work as possible (with the exception of some very kind friends). I found myself working on everything from the UI design to animation, particle effects and audio, Steam deployment, as well as many other areas I’d previously been clueless about. It was an insane learning curve to say the least, but overall I think it kept the project focused, the quality high and reduced time spent managing team tasks (no writing long design briefs, assessments, iterations, etc.) and given my financial state back then, time was most definitely not a thing I had in plentiful supply. With our small team having such a personal hand in everything throughout development it also gave us intimate knowledge of how every facet of the game and the engine worked, which helped us to identify bugs and coordinating fixes very quickly and efficiently. This, I believe, is also what contributed to a very smooth launch overall, especially considering how much we underestimated our audience numbers at the time.

A few months later we decided to expand to Mac and Linux, but with our coder departing the team, Dan and Jess starting on AMFP, and myself feeling pretty burnt out, it seemed like the best option to outsource as much of it as we could. We initially got lucky on that front, owing to the fact I knew some Ex-Interwave dev’s who had recently released a multiplatform Source title called Nuclear Dawn. They were looking for contract work, so we hired them to take on the port. They did a bang up job they did of it too, managing to get it out in only a couple of months, and for us, it was nice to sit back for a while and let someone else do the leg work. Similarly, when we were later approached by Codeweavers to help us do a Linux port, we were again happy to hand over the reins, especially since the Humble Bundle team had generously offered to help us cover the costs in anticipation for a future bundle.

I think however, this is where things started to get a bit messy. The Codeweavers Linux port wasn’t a true port per-se; it was really just a customised wrapper and had its fair share of issues which left it feeling a little ‘dirty’ (in my mind at least). The main problems though, came from the support side of things: fixing bugs was now completely in the hands of a third party, and when our support contract with them ended, so did the bug fixes. Later, things seemed a little more optimistic with the development of the native Linux port which was in beta by the time we had our first Humble Bundle. Unfortunately, the native port has never left beta, having lost touch with the original developer shortly afterward.

Throughout this time we’d also had an increasing amount of bugs coming in from the Mac port due to ongoing OSX updates, and to our dismay, we found that the ex-Interwave devs had since parted ways for jobs in various places. Without developers experienced in multiplatform Source Engine development, coupled with our own unfamiliarity with the Mac and Linux platforms, we hit a brick wall.

To top things off we also received a huge bill regarding the licensing of middleware that had been, unbeknownst to us, included with the Source Engine but not covered in the original License deal. Not only that, but we’d need to pay for a separate license for each platform released. It was a big hit financially, which put us at a loss in terms of the mac and Linux ports.

The final straw came in September last year, after what should what was promised to be a fairly straightforward PS3 port. Started in May, with the PS4 still far on the horizon and with a projected development time of only 2-3 months, it seemed like a safe goal to reach. We were excited to see how Dear Esther would be received by a new branch of gamers, but unfortunately we hit issues early on. First, having to license yet more middleware for Source, and then obtaining the additional PS3 source code for the Engine. This was all happening around the time of the departures at Valve, which unfortunately included our main contact for all things Engine related, and subsequently we spent weeks trying to find someone else who could point us in the right direction. This had a cascade effect on the whole project leading to months of delays, coupled with the contractor’s inexperience with the engine, communication problems, and then finally the PS4 release date announcement, we decided it was time to pull the plug, at significant cost to us.

We also got the underlying impression that official engine support was not long for this world, making me all the more anxious, not just about the possibility of further ports, but about the future of Dear Esther in the years to come.

Rather than feeling angry at the events that led us down this path, I felt kind of guilty, negligent even. I couldn’t help but feel responsible for our situation by the fact I’d decided to take a lesser role in the game’s development after its initial release, and that in order to tidy the mess and secure Dear Esther’s future I needed to roll up my sleeves and get involved again.

I’ve never had the capacity to code past a certain level, I think due to some right-brained visual defect, or my own impatience, and it had held me back repeatedly for over a year whilst trying to prototype ideas for a new project. Before the collapse of the PS3 port, I’d begun toying in Unity a bit. I was digging the interface and how simple it was to pick up, but was still facing the same old roadblocks until I saw a tweet about a plugin called Playmaker. For me, Playmaker is a gateway into a world I’d always considered alien – it’s basically a visual code editor, and for someone who has been using UDK on and off for the past 5-6 years, it made the process of creating functional code in Unity very natural. At the same time, I also stumbled across a post on Polycount which showed an early alpha of a plugin called Shader Forge, which closely resembles the look and functionality of UDK’s node-based shader editor. In combination with Playmaker it felt like the possibilities of what I could do were endless.

When the PS3 port collapsed, I realised that with my knowledge of Unity, there was an opportunity to not only safeguard the future of Dear Esther, but to also clean up the Linux and Mac ports and reach a wider range of other platforms. Best of all, we’d be able to keep everything in-house, at low cost, with no more licensing or communication barriers, no more support woes and no more scouring for experienced Source Engine developers to help us.

I talked to the team about the prospect of Dear Esther Unity, and came up with a proposal: I’d do a thorough evaluation of the engine and come back in a couple of months with something to show them. If I failed, we’d not be any worse off than when I started, so the risks to everyone involved were zero. This is the result of around three months of work:

Exactly how I managed to get the game over to Unity is something for another blog post, but for now, the plan is to work towards a solid, high quality, Linux and Mac build, and then eventually PC. At some point we’ll  release betas for our existing Humble Store and Humble Bundle customers to evaluate and test, and when we’ve got something that reaches a quality we’re happy with, we’ll scrap the flakey old builds and look at getting everything up and running across all platforms on Steam.

It’s probably worth noting though, that things are still up in the air on this, I’m still battling issues and have many challenges ahead, but I’m also learning new things everyday. Rest assured: we won’t release or replace anything until we’re 100% sure it’s ready and you are happy with the transition! When will that happen? I don’t yet know, but I will keep updating on here, and on twitter as things progress.

Keep your eyes peels for the “HOW?!” post next week