Without developers experienced in multiplatform Source Engine development, coupled with our own unfamiliarity with the Mac and Linux platforms, we hit a brick wall. 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. Unfortunately, the native port has never left beta, having lost touch with the original developer shortly afterward. 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. 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. 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). I think however, this is where things started to get a bit messy. 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.
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. They were looking for contract work, so we hired them to take on the port.
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. 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.Ī 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. 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. 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.
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. 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). However, as ambitions grew so did the scope of work.
#Dear esther ps3 mod#
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. 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…ĭear 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. 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 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.
0 kommentar(er)
