HiGame

During the last console generation, HD remasters became a popular trend among many of the major publishers. PS2 and original Xbox games were given a fresh coat of paint, and re-released to the world. While the reaction to this trend wasn’t universally positive, it was more-or-less accepted because of the significant jump in fidelity between 480p and 720p. This time around, the situation is a bit more complicated, and the bloom is off the rose.

Recently, I had the opportunity to interview developers from two game studios: Iron Galaxy and BlitWorks. Both of those studios are well-known for delivering ports on numerous different platforms, so their first-hand knowledge of this complicated field is exactly what I was looking for. Without further ado, let’s hear from the boots on the ground.

BlitWorks interview

Grant Brunner: Can you give some background on BlitWorks, and what your company does?
Tony Cabello: Well, basically, we’re specialized in porting games. With all the founders being involved in the game development industry for almost twenty years — we have a very deep technical background. Miguel, my partner, he’s a legend in the emulation scene. He did System 32, the Mega Drive, the Dreamcast, and a lot of other work.
Miguel Horna: Neo-Geo, Capcom System II & III, Sega Model 2.
TC: So, we started offering porting services. And over time, we are adding more services like publishing and remakes. Although it’s difficult to say what is a remake and what is a port, because there’s a fine line between them.
GB: There’s a common opinion in the enthusiast community that because the PS4 and Xbox One are using AMD CPUs and GPUs, it’s easy to port to and from the PC. Does this idea actually hold water based on your experience?
TC: Yes and no. The architecture is fairly similar to a PC, but a few details make a big difference. You have to fully understand each component in order to get the best performance. It’s easy to do a port, but it takes a lot of effort to get the max performance of each console.
GB: Since Mantle and DirectX 12 are allowing developers to get closer to the metal, does that mean good things for PC-console ports going forward?
TC: Yeah, sure. The new APIs are following that direction. And, basically, they are getting things out of the drivers, so they are allowing you low-level access. In the end, all the GPUs are more similar nowadays than a few years ago[…]
GB: And in terms of CPUs, both PCs and consoles are doubling down on more cores with less of a focus on clock speed. Is that trend a positive thing when you’re porting games to and from these different platforms?
TC: Right. The trend really helps because the mindset is closer than back in the day with the Cell processor — it wasn’t exactly in the trend. Each core had specific memory, and there was a DMA [direct memory access] across the different cores. I mean, it was a very different architecture than a set of general purpose cores that you can find in current CPUs.
MH: That’s why the Xbox 360 was thought to be easier to program [than the PS3]. Because it had three general purpose cores[…] it was more like a PC. PS3 has a main CPU, but then the other CPUs are using a different instruction set, different memory, and everything has to be communicated by DMA. So it was very hard to work with it.
GB: So if the PS3 is on one end of the difficulty spectrum, is there a platform on the other end? Something incredibly easy to port to and from?
TC: I would say the PS4 and Xbox One[…] everything else falls in between like the Vita and the 3DS. They’re in between because they have different challenges. They are less powerful, but still, they use a normal architecture.



GB: BlitWorks has ported games with a very strong focus on precise timing (Meat Boy, Necrodancer, OlliOlli). Are those kinds of games harder to execute on properly than, let’s say, a menu-driven RPG?
TC: Yeah, every time you have to deal with real time, a lot of unexpected things happen. On every platform, you’ll find a different bottleneck that keeps you away from 60 frames per second. Actually, 60 frames is very difficult. It’s so tight — it’s 16 milliseconds. If anything unexpected comes, you’ll miss a frame. And it’s so easy to miss a frame in the middle of an animation, and [ruin the smoothness].
MH: In games like OlliOlli, any alteration on the timing can make you miss a trick. The common issue with this particular game is when using TVs that do excessive signal processing. Either you activate the game mode on the TV set or you’re going to have a hard time getting used to compensate the lag in your brain, as you will have to press the buttons a few milliseconds in advance. Necrodancer is also a good example, as it has a calibration screen at the start of the game in order to compensate the lag for you.
GB: What about compensating for different controllers? Button positioning, dead zones, and the overall feel is different between controllers. Do you ever have to make tweaks to make the game feel “right”?
TC: Yeah. In every game, we have to do some degree of fine tuning of controls. This is a very subjective topic, and it’s not always clear what to do, so both our testers and the original game creator exchange very valuable feedback so the intended feel is preserved. But there’s no simple rule, just play and see how it feels.
MH: When you have a touch game for Vita like OlliOlli, and you want to port it to PS4… The menus were only built to be used by touch, so we have to create that new menu system so it can be navigated with gamepads.
GB: On the BlitWorks website, there is a page dedicated to something called “Unsharper.” You folks call it a “semi-automatic tool for converting C# code into C++.” How large of a role does automation play in a typical port from BlitWorks?
TC: Well, we started this tool because when we ported FEZ, we used an already existing tool for converting from C# to C++. This tool missed some features, and we had to finish the port manually by filling the gaps in the generated code. But with bigger games, like Bastion, on which we’re working now, this way would have been impossible. The amount of code is much bigger, so we needed to automate the conversion. The manual part is still there, but it’s not the same amount of work we did with FEZ which was very, very time consuming.
GB: Do you do the manual changes before or after the automation process?
TC: The tool is generating C++, and we do the manual changes on the C# side, so we’re constantly converting to see the improvements. The tool is actually a compiler if you look at it this way. What we do is, we adjust the C# to fit the requirements of our compiler, which is not perfect, and does not support everything.
GB: Is there anything about game ports (or the porting process) that you think ExtremeTech readers should know about?
TC: Well, what I would say is that ports can be very technical, but good ports always carry a lot of product level kind of work — adjusting the controls, getting a proper UI, getting smooth graphics. In a sense, a good port is like going back to the time when the game was being developed, changing some of the assumptions, and reworking the affected parts.
I think this is the biggest difference from doing something like an emulator which is a 100% technical thing. You just have to get the game to behave the way it did originally. In porting, there’s a lot of care about the product — exactly like when the game was developed originally, but on a different platform.
MH: If you do ports like… an automatic machine, your ports aren’t going to be good. They need a lot of care — a lot of attention. A lot of love from the team to make the port in the best possible way.

more...