Oddworld vs. PlayStation Vita

A good place to start is with the docs themselves and also the many code samples that are provided. These give you a hint as to what the hardware might be capable of and whether it will meet the demands of your project. One concern that we had at the beginning was how we would fully utilise the quad-core processor. For us it turned out that this was one of the keys to unlocking the full capabilities of the Vita.

I would agree with that in general. I think the only real similarity to the PlayStation 3 are the online libraries, otherwise everything else is quite new. This isn't necessarily a bad thing as you need to get as close as you can to the hardware and this ultimately means having to cope with significant differences developing between different platforms.

Certainly one of the biggest strengths is having a quad-core processor with real hardware multi-processing, rather than the more limited performance of hyper-threading. With a bit of work you really can squeeze a lot of power from this CPU. I suppose you could also consider this a weakness in some ways because it is difficult to utilise the CPU to its absolute maximum all the time, but overall it is a big advantage. Obviously there are no SPUs on the Vita compared to the PS3, but I think the multi-core processor goes a long way to addressing this.

Absolutely, the scope of the game and its technical requirements turned out to be an ideal match for the Vita. And judging by some of the reviews that we've had, and the players, it's the kind of game that plays very well on this particular handheld platform.

Yes, Stranger's Wrath runs at full 960x544 resolution. The screen on the Vita is a wonderful and vibrant display and it would seem a shame not to use it to its full potential. After porting Stranger's Wrath I can understand why, at the start of the project, you might think about the compromise of a lower resolution to give you a decent frame-rate. This was our approach for the first half of the project. It was only after an intense period of optimisation that we realised we would be able to run at native resolution and have the decent frame-rate as well.

To run at full resolution it really came down to fill-rate and making the necessary changes to make sure the GPU isn't overloaded for any part of the frame. One of the biggest problems for us was having a lot of full-screen passes during each frame for various effects. There's an extra overhead for doing each of these passes because a new scene needs to be started for each one, so it's a good idea to reduce the number of scenes or change the scene order to combine scenes that render to the same buffer. Playing with the order of the draw calls within each scene also led to some improvement because of the way the system implements deferred tile rendering. Another big gain came from the bloom effect where we combined several blur passes into one single pass and compensated by changing the pattern of the texture samples.

Some of the more obvious enhancements that might easily be overlooked include: using the correct CG optimisation compiler options, switching to the alternative power mode during single-player gameplay to increase the GPU clock speed, and reducing the resolution of shadow, reflection and other effect buffers.

Well, we wanted to use the new touch-pads for a start, so we came up with several uses for these. There was a bit of trial and error involved to see what works and what doesn't. When the game was released I think there was some oversight on our part with the punch action being assigned to the back panel. This was pointed out in quite a few reviews and it's something that we've now addressed in the forthcoming patch. We've now limited the active area of the rear touch-pad and this has made a big improvement as it's now quite difficult to press this accidentally. The patch also includes an alternative control layout to avoid this completely if the player wishes. We also use the back touch-pad for other specific uses such as climbing and descending ropes, and rowing for when Stranger is controlling a boat.

Because there are so many possible configurations for using the touch-pad it's something that you need to address early on in the project otherwise it may catch you out later.

Well, Cross Save actually uses TUS (Title User Storage) system as a way to facilitate the transfer - that is limited to 1MB, something we were aware of when we did the User Generated Content system in Gravity Crash PS3. So to be clear there's no dedicated Cross Save set-up as such, it's a part of an existing system. With Stranger, the saves can be up to 5MB, as the game stores a lot of information as you can save absolutely anywhere in the game, so if you're three-quarters the way through a level you might have a few thousand spent "shots" in the level, the positions of these are all stored, so this bumps up the save size.

Well there was no PSGL library for the Vita at the time of development so the task of porting the game was really quite a challenge. Our approach to doing the port was to emulate as much of the system as possible. Most of the game code is already a decade old and so trying to modify things at a high level would have given us too many problems further down the road. And with just myself working on the code this may have ended up being too big a job.

So instead I basically emulated as much of the existing system and rendering calls as possible. I think, with hindsight, this turned out to be the best approach because it allowed us very quickly to get the game up and running on the Vita in a short space of time. Obviously there are performance issues with basic emulation but once the game was running suitably and without graphical errors I could then use the developer profiling tools that come with the kit to target only the optimisations where they were definitely needed. And through a long series of optimising iterations we got the performance we required with minimal impact on the original code base, which also meant it spent less time in testing.

Apart from those that you mentioned the other main difference is the reduction in texture size, although this is acceptable due to the smaller resolution of the device. We also halved the density of the world decorators. At first we were worried this may affect the richness of the environments, but in the end it was barely noticeable during gameplay that we had made this alteration. I think this must simply be due to the smaller screen and that you are able to get away without having to fill it with too many objects.

Apart from the lower texture sizes and some simplification of a couple of character models, the final product is essentially the PS3 game.

The biggest challenge without a doubt was getting the game running at native resolution. It was actually only half way through the project when we thought that it may be possible. Up until that point we were looking at running at a lower resolution just so that we could achieve 30FPS. But as we went through a series of optimisations and with some invaluable on-site help from Sony we eventually managed full resolution and in some areas of the game we are getting towards 50FPS, which was quite a nice surprise.

Fortunately Sony provides some excellent profiling tools with the developer kits. Without these there is no way that we could have reached the final quality that we did in the same amount of time. They really were invaluable. It's not really worth trying to second-guess which changes will make a good optimisation. On several occasions what I thought would make a great optimisation turned out not to be and in fact in some cases they were detrimental. So I ended up just trusting the profiling tools to get the biggest wins.

"One of the biggest improvements that day came from making use of the alternative power mode... which allows you to increase the GPU clock speed while disabling the WiFi during gameplay"

After optimisation of the graphics the game became CPU-bound. Again the profiling tools are excellent for analysing the game code and one of the best gains that we got was by moving all of the rendering calls onto a separate thread. We noticed in the profiler that a considerable amount of time was taken in the draw calls. Part of the reason for this is that we were not using pre-computed objects and so passing the raw draw data for each call was quite expensive. But by moving this onto a separate thread and getting it to run on another core we had a much better utilisation of the CPU with a big gain in frame-rate. Without doing this I don't think we could have run at native resolution.

We also had some excellent on-site help from Sony. We had one of their best guys for a day and they gave us plenty of advice and optimisation tips. Admittedly one of the biggest improvements that day came from making use of the alternative power mode on the Vita which allows you to increase the GPU clock speed while disabling the WiFi during gameplay. But, of course, this just emphasises the great importance of reading manuals.

Not sure it's a major development lesson, more a case of coming to the realisation you can do a lot with a little bit of patience. We're incredibly proud of Stranger on the Vita, especially with the time and manpower on it, so that little machine is a beast and can likely do much, much more.

It's fan service as well as an experiment. Stranger's Wrath HD is the first Oddworld title to have leaderboards in it, so we wanted to test the water as it were with an existing title. So we added that into the Vita version at the end of the project's development, but held them back due to some technical issues. We were also faced with a need to reduce the size of the PS3 version of the game from 3.2GB down to something more manageable, as such we've reduced it to around 1.5GB, so we decided to use that opportunity to add the leaderboards into the PS3 version too. We're aiming for releasing those in March of this year.

"We're incredibly proud of Stranger on the Vita, especially with the time and manpower on it, so that little machine is a beast and can likely do much, much more"

From a business point of view it'll be interesting to see how many people will replay parts of the game to improve their standings as well as looking to see how many people might pick the game up now just because we've added leaderboards. It's about community engagement to a degree and allowing our community to do whole "I've just beaten you at..." thing. It's going to be interesting.

No, I think it's safe to say we're done now with Oddworld: Stranger's Wrath HD - that includes the chance of doing an Xbox 360 version, the last of which we heard was Microsoft will not touch the title, unless we did a direct sequel to it.

You hit the nail on the head actually. When these updates to Stranger's Wrath are completed then the entire company will be on Abe's Oddysee New 'n' Tasty. We're now 15-strong in addition to a few of the original Oddworld Inhabitants team who are back for the ride, something we're incredibly proud about. I think that project has about 22 people on it now, so we've grown, our budgets have grown and hopefully indies will start to bridge that gap between the traditional definition of "indie" and "AAA" projects, especially in this age of digital distribution.

Indeed, it's not been the rosiest of times. However, from our point of view we've done fantastically well, being the number-one purchased title in the SCEE region during December and January, and the third best in the SCEA region, and it's still doing well in both. We have a further two titles in development for the Vita that we've already announced and another we haven't so it's all good and we're going to keep supporting the platform until such time as it doesn't make sense to.